Some more: -) Figure out / define the best way to adopt dojo widgets to tapestry components. The internals are more or less in place, i'm just refering to adding functionality in a base component class that manages parameters. Here are the options: - For each dojo parameter, define one in our component, add a getter. Then on render, collect'em all, build a JSON from them and pass it to a js that builds the widget. Additionally, there may be an 'options' parameter allowing the user to specify even more dojo parameters (using JSON syntax). This should ideally get appended to the JSON we build from the normal params. This is how we currently integrate dojo in Tacos and how i started adding stuff in Tap4.1 - Do not define dojo parameters in our components. Instead go through informal parameters, find those starting with a given prefix (perhaps 'dj') and append them in a JSON to be used for building the widget. This is a step forward, but: users (+ tools) would like to have all of those params defined and quickly look them up, we can't make use of inherit-informal-params or renderInformalParameters(). - Define dojo parameters in our component jwc. Do not add getters in the java file, just define a Set containing those params. On render, go through the formal parameters and build the JSON from those contained in the Set. Optionally append those starting with a 'dj' prefix. I like this solution. It keeps code simple, allows us to offer all current dojo params and future ones as well. I've got code for all the above, but would like to hear opinions / options before committing
-) Really, really watch out for those component generated unique ids. Let me give a real-life example: ComponentA contains ComponentB in a loop. ComponentB renders unique Ids. ComponentA appears in page twice. Page is rendered, ComponentB of first generates ids: id, id$1, .. id$9, and of the second: id$10, .. id$19. First ComponentA is asked to rerender due to user action and now needs to render ComponentB 15 times ... ooops! Of course a solution exists, but do you know it / like it? What if you don't have access to ComponentB code? -) Don't know if this is in or planned but what about direct client calls to hivemind services? This is not in tacos partial-render spirit but it does have advantages in some cases... >From Jesse Kuhnert <[EMAIL PROTECTED]>: > Looks great guys! Esp all of the internal java code refactoring that's been > happening. Makes me very happy to know it's improving :) > > I'm going to be trying to finish up the majority of features by the end of > the weekend for tap 4.1 and wanted to know what everyone feels is really > crucial to get in there. (keeping in mind time constraints). Either way a > definitive list would be very helpful. Andreas should be able to assign JIRA > issues to me/4.1 specifically once a good list is made. > > These are the broad brushstroke items I expect to have done: > > -) Ability to package dojo js within jar - done > -) Rewriting of tapestry js to use dojo package system + test - done > (partially) > -) Native (ie non-enhanced class) support of ResponseBuilder-ish interfaces. > done > -) DojoResponseBuilder (not completely the same, but similar ) - done > -) JSONResponseBuilder - For json style request/responses > -) Leonardos very cool AjaxEventSubmit component in the form of a new > annotation called EventListener (the xml .page .jwc has yet to be defined). > This one is obviously a lot easier to use now that we have control of > tapestry ;) > -) ScriptTemplate/ PageRenderSupport control - done (ie we can control via > ResponseBuilder exactly what script output is written, filtering by the > component contributing it...The ResponseBuilder is also now more or less the > new PageRenderSupport object instead of the Body component.....Allowing cool > things like Dojo event.connect calls for initialization script stuff > /etc...) > -) Form handling - AjaxEventSubmit - ish submission of forms via > EventListener annotation. Will also be supporting optionally validating the > form (on client and server ) when submitted, as well as controlling which > form components have their values submitted. (for partial submissions) > -) Will be making small fix to Any component to eliminate unique id > headaches > > Anything else major that I'm missing? (A jira issue for handling Direct > component renders would be welcome, but isn't something I think will make it > into the first alpha release, probably the second) > > If possible I'd appreciate it very much if Andy took over managing this list > and getting the right things into jira and assigned to proper > milestones/people etc...but that isn't absolutely needed. (don't want to > sound too bossy ...umm. Please? heh ) > > -- > Jesse Kuhnert > Tacos/Tapestry, team member/developer > > Open source based consulting work centered around > dojo/tapestry/tacos/hivemind. > -- _______________________________________________ Tacos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tacos-devel
