and for chapter 8: - p213, cite the url and date - p214, 1st bullet - passwords are not always stored. (refer to later section) - p214, make clear that aut.permission is optional - p214, last two sentences start alike, please rephrase. - p215, 1st code example, please explain the code and refer to the sections where it is discussed in more detail - p215/216, the list on p216 seems also to belong to the sentence on p215 "the controller ... multiple actions". Because of the code listing the connection is lost. Adding a phrase like "An explanantion of the actions: " after the code listing and before the text will help - p216, not_authorized - how does this relate to the redirect by auth.settings.on_failed_authorisation (p225) - p216, "all are exposed ... to restrict", where /how to restrict. As per example on p218? - p216, subclassing auth. Can you provide examples or refer to ... - p216, last word "exmaple" -> "example" - p217, code example. auth refers here to the global variable auth as defined in the example on p215. As with the db global variable convention, please indicate the same in this chapter - p217, is there a seperate mail chapter? Yes: make a reference. No: make one - p218, appadmin interface doesnt use the markup and perhaps refer to the appadmin section (do we have one?) [p218, we might some proper user admin gui instead of using appadmin] - p218 r eblocking users. When will blocking users be active? On session expiration (when/how), logoff/login etc. - p218, last part of restrictions: "you can also block" and "can be restricted". What is it? Blocking seems to be the right word here (restricting for me means that there is still some parts accessible) - p218, recaptcha now only lists a partial signature. As per previous chapters, please list the full signature - p219, is the code listing correct? first "auth_table = db.define_table", followed by "auth_table = auth.settings.table_user" [ perhaps we need to include a helper in auth to do some basic chores and check onuser defined auth tabled ] - p219 "you can add any field ... cannot remove the required fields shown...". What you are saying is that the example shows the mimimum required fields, and more fields can be added as needed - p220, why not list the default supplied atlernate methods as you do with the validators? - p221, first half is a confusing text part. It seems to assume that some technical knowledge is present, and perhaps a reference can be made to apache .htaccess files that set up such a scheme. - p222, GAE "api is a little different but not too much". What is different? using login_form instead of login_methods, and no chaining. - p223 " although we suggest so" - why? - p223, use a bullet list to display the various actions (as per previous listing of attributes and methods/actions) - p224, first metion of crud. refer to the later section where it is discusse din more detail - pp24, the parts starting with the "row" code listing and " assuming following" should stand more apart [ accessible query on the todo to get something simmilar on GAE ] - p224, please explain the example - it now stands on its own - p224, first paragraph of the decorators should perhaps already being mentioned earlier (you first dive into the details and technical parts and the it is, "but here is how you should really do it" - p225, perhpas give more meaning full action names instead of " function_one" - p225, you really want users to run function_five? - p225, function_six should better be explained using the return example as per the other functions. - p226, refer to the crud (currently in ch 7)? - p226, the code listing is not explained - p227, download authorisation. Can you explain why it is different? (the reason behind it) - p227, "basic authorisation" how does this relate to the "basic" on p221 - p228, make use of a bulleted list - p229, "as dicussed prveiously", please more specific references - p230 second line "funciton" - > "function" - p230, code listing, some lines are not wrapped (python wise) correctly - p231, the "..." in the listing will be filled?
Hans On Sun, Jul 12, 2009 at 12:17 AM, Hans Donner<hans.don...@pobox.com> wrote: > And for chapter 7: > > - p174, halfway " can be done in the view or the action". I assume > action is defined earlier - Perhaps a quick reference. > - general, sometime you amke an update of a previous example. Please > make explicit in the code, eg by using comments, where the new/changed > stuff is. Makes it easier to spot > - p175, 1st bullter re the validator. refer to later section covering > validators > - p17s, lower part. Explain that this message is generated by default > by the validator in the used example > - p175, 3rd line below "bee submitted" > - p177, last bullet. consider switching the the last sentences > - p178, re the explanition of accept and errors. Perhaps add that > accepts calls the validators and the optionally onvalidate that doe > the actual adding of error messages > - p178, keepvalues - also covers the signature of accepts. should be > before the keep value > - p179 - what is field d doing in this example? > - p 180/181 multple forms/self sunmission. Both refer to SQLFORM that > is only discussed later > - p180 multiple form submission. So by leaving out the session > variable where open again for double submission. Can we prevent it, or > did we open a new hole? > [note: perhaps we need more explicit ways to deal with this in web2py, > as leaving out a session variable can be overlooked] > - p181, self submission - what is the use case for having this? teh > code example on shows how it is done, but gives little information on > why it is done... > - p182 '( it can be psddrf with the fields...)' - how? > - p182, last part - gae stores in the db > - p183, last half ' single biggest time saver' - why? how? > - p183, just below previous: how and why to overlaod the xml method. > Relevant example? > - p184, sequence of the fields is not in line with the signature (it > is in other cases) > - p184, consider how the senteneces are phrased. Most orther cases > start with the fieldname, here it is more messy > - p185, first bullet. Bit messy. Starts with " optional arguments are > ... starting with underscore'. just below a argument name is shown > without an underscore. perhaps a bit more background re the _ > attributes > - p185, insert/update. be more specific if a record is passed, or just an id > - p186 - sqlform in html. This is a very special case. Perhaps list > why/when to use this. Compare it with the custom variant > - p186, code example. Correct that session is missing? make it explicit > - p186 - why is the custom vraint only listed several pages later? > - p187 - re the formname, where is it used for. What is the effect of > setting it to None (looks like what has been disucssed on 180) > - p187 - sqlform and upload - GAE is different > - p187 - perhpas make the filenaming convetion explicit: > <table>.<field>.<id-part1>.<id-part2>.<original extension> > - p188, example refers to 'db', which is a global variable and has > required name. be more explicit, also in the DAL section that is a > aconvetion to name the DAL global variable db, and is used as such in > the book > - p188, html output bottom: reformat it? > - p190, link to referencing records. Make a reference to Chapter 6 / DAL > - p190, bottom, 'appadmin' is mentioned here. make a reference to > where it is explained in more detail > [ note re page 191, add a similar upgrad to linkto for SQLFORM as we > did with SQLTABLE] > - p192, SQLTABLE is mentioned, make a reference to where it is > explained in more detail > - p192, pre-population. Comapre it against setting field.default ? > - p192 SQLFORMwithout IO. As described now, this is the usecase for > onvalidate. Perhaps better to use an example where one form touches > multiple tables? > - p194 and further: include full signature for validators > - p194, introduce the three types of validators (bais, db, custom) > - p196, in-range validator, refer to followong python convention (for > users not known with python the < max ins etad of <= max may be a > surprise) > [ note: perhaps rename the converting validators such as IS_LOWER to > MAKE_LOWER or CONVERT_LOWER ?] > - p197 is_list_of, first half of first sentence makes it confusing > - p197, is_time, refer to formatting in is_datetime? > - p201, is_lower is already mentioned on p197 > [ note: consider renaming CRYPT and CLEAN to make use of naming > convention, see also other note] > [ note: for backwardcomp we keep the old names, perhaps add a warning > output log message that these names have changed? ] > - p202 - validators can now be derived from a base class > - p203 - source example is outdated (nor derived from base class) > - p204, widget listing - consider adding a small brake after line 10 > (for the text below) > - p205, convetion of id and class value - refer to specific section > - p205, consider giving crud it's own chapter > - p205, first code example crud 'improt' should be ' import' > - p206, attribute listing. Follwoing earlier sections, make use of a bullet > list > - p208, idem > - p209, onaccept, onvalidate - make post/pre db io action clear > - p210, custom form should be earlier > - p211, first sentence 'tags in form... the forms' -> ' Tags in forms .. it' > > hans > > > On Sat, Jul 11, 2009 at 8:49 PM, Hans Donner<hans.don...@pobox.com> wrote: >> Reading through Ch 6: >> - p143 - perhaps a note that the term SQL is genericly used (GAE does >> not use SQL) >> - p144 - bit confusing to still have SQLRows, ...Storage, ...Query, >> ...Set and ..Xorable; perhaps prefix them with DAL insetad of SQL >> - p145 - the SQLXorable description is unclear. I still cannot explain >> this to a non-developer (even when I peek at the data). Is it relevant >> here? >> - p145 - the image needs updating (still uses SQLDB) >> - p145 - the image is now confusing, just before the Field is >> indicated as to be derived from Xorable and in the pictures it looks >> like it is the reverse. I believe the image is trying to convery >> another story, but it is not clear what story and where it is told >> - p146 - assume it is on the default port, but some connection strings >> still have a port in them >> - p146 - firebird has a user insteda of a username >> - p147 - halfway it is mentioned that DAL can make multiple >> connections to different databases. Please refer to a section where >> this will be described >> - p147/148 - migrations may need a sepcial paragraph header, as it is >> quite an important subject >> - p147/148 - perhpas also mention good practice re the usage in >> production and development environments >> - p148- the coding example halfway still uses SQLField >> - p148 - uploadfield or " uploadfield", the usage of quotes are not >> always consistent >> - p148 - mention of SQLFORM, see earlier comment >> - p149 - the italic section, why is the distinction important? >> - p149 - a list of default widgets - where will it be listed? >> - p150 - second bullit, " will di displayed" >> - p150 - "25% more storage" / "reduced the amount of data" seems to >> contradict, and could use an explanantion >> - p151 - id's starting at 1, is backend specific (not on GAE) >> - p151 - halfway, still mention SQLField >> - p152 - restrats at 1 - is backend specific (not on GAE) >> - p153 - commit/rollback - is backend specific (not on GAE) >> - p153/ 154 - executesql / indices. Text is contradicting, mention >> with executesql the usage for selects is normally not needed, but is >> more common for indexes >> - p154/155 - "this is one the way .. ", consider revising this part. >> web2py follows the design for a technical key, which is a good >> practice. many db's use only logical keys, which is another practice >> but (currently?) not supported by web2py if it doesn't have a >> technical key as well >> - p156 - the one-line examples seem to be chained, could perhaps be >> made more expicit in the text for those readers doing only the reading >> and not the live examples >> - p156 bottom - field selection is backend specific, gae works differently >> - p157, the example at the bottom; can this be typed into the interpreter? >> - p157, doing this kind of db in a view is not by everybody considered >> good MVC practice >> - p158, orederby etc - is backend specific (not on gae) >> - p158, " an filed is derived from an sqlxorable" this seems to come >> from nowhere/blue sky >> - p158, logical operators. Perhpas mention explicitly that AND and OR >> are not supported due to python restrictions >> - p160, relations - not on gae >> - p161, INNER OUTER JOIN ? >> - p165, helpers? Perhaps make a reference to a previous chapter >> >> Hans >> >> >> >> On Sat, Jul 11, 2009 at 6:33 PM, Jose<jjac...@gmail.com> wrote: >>> >>> >>> >>> On 11 jul, 14:57, Massimo Di Pierro <mdipie...@cs.depaul.edu> wrote: >>>> Chapters 7 and 8 have been revised including corrections from Mr >>>> Admin, Fran and Jonathan. >>>> >>>> web2py_manual_678.pdf >>>> 1982 KVerDescargar >>> >>> Massimo >>> >>> In the page 146: >>> >>> The ports of mysql and postgre are equal. >>> In firebird already it is not necessary to put the port 3050. >>> >>> Jose >>> >>> >>> >> > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py Web Framework" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
