2011/5/20 Justas <[email protected]>: > On 05/20/2011 05:18 AM, Douglas Cerna wrote: >> >> [warning: tl;dr threat below, so have your coffee next to you...] >> >> Hey everybody. >> >> I've created a branch for my experiments with jQuery UI. It's at: >> >> lp:~replaceafill/schooltool/schooltool_jquery-ui >> >> Also, I've set up a testing instance at: http://69.164.203.135:7080 You >> will want to add a course. > > Nice work! (and a personal thankyou for the test instance ;) ) > >> Here's what I've done so far: >> >> 0. I download the default js and theme files and added them as resources >> to the default skin. > > Ok... unless menesis finds them packaged somewhere of course ;)
http://pypi.python.org/pypi/js.jqueryui :) > >> 1. I ported the add form for courses to z3c.form. The current form is >> implemented using an<addform ...> zcml directive. Please, let's kill those >> :) > > +1 :) > >> 2. Having the new form ported to z3c.form makes easy to extract specific >> parts of it using the macros provided for each part of the form (header, >> errors, form body, buttons, etc). > > Let's assume that at some point our (form) views will be able to render > themselves in "inline format". > >> 3. So, I subclassed this new form into a new view that renders only >> the<form>...</form> part and I attached javascript behaviour to the two >> form buttons (Add and Cancel). This behaviour allows the form to send the >> POST data and receive the response using jQuery, so we avoid the full reload >> of the page. Any validation error is inserted into the form body using >> jQuery. This "inline" form works correctly by its own. > > Cool. Though I'm a bit concerned with the amount of customization done in > the "inline" course view class. > >> 4. For the last step, I customized the course container view to create the >> actual jQuery UI dialog and insert the inline form. The set up of the dialog >> uses only four self-explaining options: >> >> * autoOpen: false, >> * modal: true, >> * resizable: false, >> *draggable: false >> >> The width of the dialog is calculated based on the width of the inserted >> form: >> >> width: $(addform_id).find('form').width() + 30 >> >> and the height of the dialog adjusts itself to height of the inserted form >> (when the form displays validation errors, the dialog resizes >> automatically). > > Great! > >> Finally, the container view attaches all the javascript behaviour to the >> "New Course" action button and shows all this functionality only if the user >> can edit the container (remember that the course container view is public). > > Oh, a very good point there. What happens if the session expires and user > gets magically redirected to login screen while clicking in such dialog? > >> Some comments and questions: >> >> * We're not using jQuery modal forms per se. Just a modal dialog. This >> means that the dialog doesn't have any buttons. However, inserting the whole >> form in the dialog saves us trouble regarding, client vs server validation >> and translations. You can see the translations working in the inserted form >> in the testing instance. I enabled two languages, English and Spanish. You >> can change between them using the links next to the "Log Out" link. > > I think this worked out pretty well. > >> * Our default z3c-schooltool-form.pt template renders the ul.errors >> element conditionally. For the inserted form I needed something that was >> always rendered, so I used div.required-info for displaying the errors. No >> biggie, it can be fixed easily. > > I would prefer a full form reload here. > >> * The dialog is reused, this means that if the user closes the dialog or >> clicks the Cancel button, the data and validation errors are kept and >> displayed again if the user clicks the "New Course" button again. You can >> test this: click "New Course", click Add (you'll get a validation error), >> click Cancel (or click the X in the dialog title bar or press ESC), click >> "New Course" again and you will see that the validation error is still >> there. We could retrieve a new form on each click on "New Course" if you >> think that's appropriate. > > A full form reload here would be arguably nicer. Also, maybe we could > avoid loading *all* forms on page load. > >> * Justas and I already talked about having a better way to attach >> JavaScript behaviour to our action buttons, and I think he has an idea on >> how to do it. > > Form id seems to be generated by the view. If somebody writes "add > student" and "add teacher" views but forgets to make their ids different, > could this be a problem? Two forms with same id in the page? Say > "gradebook" and "gradebook"?.. > > If action button JS is added by action button viewlets themselves, they > could append, say, their adapter names or such to the loaded form div. > >> * Finally and less importantly, we should roll out a jQuery UI theme with >> SchoolTool colors. That orange title bar for the dialogs looks weird. > > Yes, they do look odd. But that's for the (near) future. > >> My next goal with this task is the datepicker. Specifically, how to >> display the appropriate translation based on the browser's locale. >> >> Feedback and comments are welcome. > > A very nice prototype! > > A mental exercise... > > Can we write a pure JS function, that, given an action button: > > 1. takes it's target link > 2. creates a jQuery dialog > 3. loads the inline version of the target page (action button link); it > should put some variable in the request header asking the page to render the > inline version or something, then ST machinery could parse the (get/post) > headers and either render the inline version of the target page if available > or return an empty redirect to the target page. > 4. whenever our function recieves a result header with redirect, > window.location is set to the redirect target, if not - dialog div's > contents are replaced with result contents > 5. the function binds all form buttons to post the form and do step 4 > with the results > > TT wizard could work; calendar event adding + resource booking could work; > container delete confirmations could work. > Step 5 is very risky, of course. We probably don't want to bind with ALL > buttons in the page. Maybe only those without onclick set. And we may want > to bind cancel button to submit the form and close the dialog. _______________________________________________ Mailing list: https://launchpad.net/~schooltool-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~schooltool-developers More help : https://help.launchpad.net/ListHelp
