I was thinking of something a little bit simpler perhaps.
I know with dojo at least, I can generate a base URL that would be
able to hit the form component of the specified field(s). I can then
decide to either do the default, which is pass in the formNode to
dojo, letting it embed the whole form...OR, I can pick and choose
which fields to send.
In your case, I would submit to the form, only sending the data of the
selected combo-box. Then, because your request would ask that nothing
else be done, the request would flow the block you had asked be
refreshed (the dependent box) and let it render, which should
hopefully satisfy the If statement because the first value had been
selected.
I like the above mentioned approach because it maintains state, and
because it's not a giant leap in learning for most people.
With that being said, you also highlight what more "advanced" users
seem to be wanting, which is more JSON semantic approaches to invoking
server methods, ie hivemind services...
I think ultimately there may be slight performance gains to the latter
approach, but it complicates the clients job considerably. Perhaps we
are finally getting into the area where special circumstances have to
start being accounted for for each specific component. Such as a
simple list which doesn't need any html to come with it. ...
I don't see why in your particular case you couldn't use the
direct=true approach, which would avoid touching any of those DB
dependent render areas. Unless of course you are in a loop, then
things become harder....
There has to be a middle ground somewhere. If I add something in I'd
like to at least ~think~ it will be generic enough to be useful in
other circumstances. God damn JSON is really biting at my heals
now...Bad JSON bad! (sorry...thinking cartman here)
Am I making sense? Ok...So I guess because I've started using JSON
with the grid, there are probably plenty of other components ripe for
this kind of specialised more efficient choice....I think I can
bravely sort of determine that a component is a ComboBox (or whatever
it's called in tapestry) and decide to render a JSON block as the
output instead of HTML.
Does this sound right to you?
I can see from your posting that you have a very clear picture of
what's going on overall, why don't you help add some of this into
tacos? Or split it up, or something. I won't ignore patches I assure
you. (unless they aren't umm..optimal, but I don't think yours
will..heh)
let me know so I don't kill myself on something not getting used..Not
that I won't use it myself, but first things first...
jesse
On 11/9/05, Leonardo Quijano Vincenzi <[EMAIL PROTECTED]> wrote:
> Cool. I'm currently testing a Submit-based approach using
> tacos.formSubmit(). Now, there are some backLink / forwardLink params
> I'm removing on purpose, to avoid my page from changing after the
> submit. I hope I am right... hehe
>
> As for the functionality, I guess we can have 2 approaches:
>
> 1) The simpler, less performant option: Simply submit() the whole form
> but don't refresh the page. That's the one I'm currently implementing
> for my Friday milestone. It has, for me, 2 caveats:
> a) The whole form is submitted just to update one value. That's
> sub-optimal.
> b) We are changing server-side state for only a submit operation. Keep
> in mind that I'm taking the approach of having a lot of nesting levels
> on the component. My component could be embedded in a full 30+ component
> tree. Some of the other components could have nasty side-effects when
> submitted (the basic example is this refresh / submit / cancel dilemma:
> We certainly don't want to register a new 'Client' just to select his
> proper US State from a Country / State select combination).
>
> 2) The more complex option (IMO) of directly invoking listeners. Those
> listeners might not be in the same page. For example, I might implement
> a special "ReferenceService" which only generates data for the
> PropertySelection objects. That way I can go and do something like this:
>
> /reference.svc?name=states&country=US
>
> And it would get me only the states for United States. Then I'd avoid
> all other page generation (think of a large page with lots of
> mini-components that hit the database). That's one choice... the other
> one being a single listener:
>
> public void countryChanged(IRequestCycle cycle) {
> ....
> }
>
> It would update a server-side collection of states with the new
> information. Then I update the states component.
> I guess, for the sake of simplicity, we can always get 1), see if it
> works, and see if 2) is really needed.
>
>
> Jesse Kuhnert wrote:
> > I think there have been enough postings about the submit functionality
> > that I feel comforatable addressing it head-on. I think I will create
> > a wiki page listing the requirements and assumptions I have and let
> > other people add-on/change what I start.
> >
> > But, to answer your question sort of immediately, the options are
> > fairly limitless. The only caveat I would place is that whatever
> > functionality is used, the page should more or less look the same,
> > code-wise, as it would without the ajax, just so it stays more
> > intuitive...Ie: you will probably have something like:
> >
> > <select id="master" ></select>
> >
> > <span jwcid="@If" condition="ognl:master != null (you know what i mean)">
> > <select id="optionBasedOnMaster"></select>
> > </span>
> >
> > It's pretty incredibly easy to add arbitrary parameters of data to a
> > dojo io request. The AjaxDirectService that you hinted at already
> > takes parameters, not caring if they come from a form submission or
> > link request. It's all the same :) (AjaxDirectServiceParameter).
> >
> > Not knowing exactly what you are expecting to happen on the client is
> > why I think I'm just going to have to go ahead and provide the full
> > suite of functionality in some sort of AjaxSubmit button. There are
> > too many possibilities...
> > -) Only updating the selected value, and then only refreshing the
> > select list depending on it. This also brings up whether or not you
> > want validation to occurr? If so in this scenerio it probably doesn't
> > make sense to validate the whole form? Maybe for some it does...
> >
> > -) Choosing which type of listener...Ie refresh/cancel/submit...etc..
> >
> > -) Disabling validation optionally on all or some parts of the forms
> > validation delegate...
> >
> > -) Optionally submitting only partial parts of a form. Ie only some
> > values change and not others.
> >
> > This is fairly easy to do already, but I don't want to hack anything
> > in...To be fair to you though here is a quick snippet of javascript
> > that you might use to do it..:
> >
> > <select id="master" onchange="javascript:return myFunction(this.value)">
> > <option value="1" >Numba 1</option>
> > <option value="2">Numba 2</option>
> > </select>
> >
> > <script>
> > function myFunction(value) {
> > dojo.io.bind( {
> >
> > });
> > }
> > </script>
> >
> > You can use the tacos methods, but you'll have to find a way to get a
> > base url string. Refresh might do it...or simply declaring an
> > ajaxdirectlink component, but instead of rendering it doing an
> > ognl:component:yourlink.getLink().getAbsoluteURL() to get it.
> >
> > The relevant dojo page is here:
> > http://dojotoolkit.org/docs/intro_to_dojo_io.html
> >
> > Otherwise, I'll probably try to put the component together later
> > tonight, which will mostl likely spill into tomorrow, and even extend
> > until friday. :) I'm sure there will be enough pieces in place to get
> > the functionality you want by tomorrow though...
> >
> > jesse
> > On 11/9/05, Leonardo Quijano Vincenzi <[EMAIL PROTECTED]> wrote:
> >
> --
> Ing. Leonardo Quijano Vincenzi
> Director Técnico
> DTQ Software
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
