On 6/2/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]
> wrote:
Yeah this is one issue I scratched my head many times over trying to figure out. If we could use annotations only in tapestry and ditch those damn .page .jwc files this would be so easy. (People don't seem to understand how incredibly different the design can evolve without these xml constraints ) .
I'm open to ideas on this one. I've added a new IWidget interface as well as two base abstract classes for widgets (form and normal widget) as a start. Feel free to go in and start playing. If we don't like something we can always revert, that's what source control is for ;) It may take a few iterations and playing with things to get this right but it's a really important part of this new functionality so I'd be very grateful if you wanted to tackle it ;)
I have a whole new infrastructure being set in place for these situations. You will find org.apache.tapestry.services.impl.ComponentEventInvoker / ComponentEventConnectionWorker strive to provide a central ~internal~ place to connect all of these things together.
The form logic is forcing the addition of deferred script processing (because of these client id issues), but I've added getClientId to the core IComponent interface for scripts to bind to to help these situations.
Ideally I'd like the API in general to just work around IComponent.getID to reference components, and only use getClientId when doing _javascript_ bindings.
This new event connection infrastructure + deferred script binding ability is a great place to provide smarter scripting logic where we can reduce the output js size as much as possible.
Yes, direct calls to hivemind services are most definitely something I want to handle. (Ideally starting with JSON return type stuff to begin with.) I was thinking a simple IEngineService that invokes things on a hivemind service would make the most sense.
Because the ResponseBuilder logic is now integrated into the framework we don't have one central engine managing all of this logic anymore. (Ie AjaxDirectService). All services get the new response builder functionality by default.
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
Yeah this is one issue I scratched my head many times over trying to figure out. If we could use annotations only in tapestry and ditch those damn .page .jwc files this would be so easy. (People don't seem to understand how incredibly different the design can evolve without these xml constraints ) .
-) 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?
I have a whole new infrastructure being set in place for these situations. You will find org.apache.tapestry.services.impl.ComponentEventInvoker / ComponentEventConnectionWorker strive to provide a central ~internal~ place to connect all of these things together.
The form logic is forcing the addition of deferred script processing (because of these client id issues), but I've added getClientId to the core IComponent interface for scripts to bind to to help these situations.
Ideally I'd like the API in general to just work around IComponent.getID to reference components, and only use getClientId when doing _javascript_ bindings.
This new event connection infrastructure + deferred script binding ability is a great place to provide smarter scripting logic where we can reduce the output js size as much as possible.
-) 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...
Yes, direct calls to hivemind services are most definitely something I want to handle. (Ideally starting with JSON return type stuff to begin with.) I was thinking a simple IEngineService that invokes things on a hivemind service would make the most sense.
Because the ResponseBuilder logic is now integrated into the framework we don't have one central engine managing all of this logic anymore. (Ie AjaxDirectService). All services get the new response builder functionality by default.
>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
--
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
