struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Cooper" <mart...@apache.org>
Subject Re: parameters on ajax calls
Date Sat, 28 Oct 2006 17:02:47 GMT
On 10/28/06, Musachy Barroso <musachy@gmail.com> wrote:
>
> I can't think of any simple case that wouldn't be solved using a form,
> and yes we could use Dojo's for that. The problem is that if you want to
> pick just some elements of the form, or some elements from different
> forms, or even more than one form, then I think just dojo's  "formnode"
> won't do.


Picking some elements is supported in Dojo by using a filter. You're
correct, though, that there is no support for picking elements from
different forms. But what is the use case for that?

Another thing is that this syntax can support individual
> elements and forms together, like
>
> parameters="val={someElementId}&{formId}"


I'm not sure I understood this bit. What are you trying to accomplish here?

One other point that would need to be considered here is encoding. Would you
just encode everything? Typically, field values get encoded and ids do not,
but there doesn't seem to be any way to distinguish between them here.

I guess I'm pushing on use cases here because I'm not in favour of adding
arbitrary functionality to the framework without having a good reason to do
so. Lots of little things like this add up to greater complexity for the
user (not to mention the code base), and without good use cases, that
complexity isn't bringing any value.

--
Martin Cooper


musachy
>
> Martin Cooper wrote:
> > On 10/28/06, Musachy Barroso <musachy@gmail.com> wrote:
> >>
> >> It would be(if it is at all) in all tags that make an ajax call. The
> >> other way would be to do it in the href attribute directly, but I find
> >> that one more confusing(in that case the parameters would be in the
> url,
> >> on the other we are using dojo's "postContent" argument for the
> >> request).  They can always specify a "handler" and do it themselves,
> I'm
> >> just trying to keep people away from javascript as much as possible
> with
> >> these tags. I'm biased about this solution 'cause this is the way we do
> >> it in ajaxtags and people use it a lot. Do you have anything in mind?
> >
> >
> > In the scenario you described earlier, you used a text box. Since this
> > is a
> > form element, why would you not just post the form? That way, you
> > don't need
> > to mess around with individual element values. And as you're no doubt
> > aware,
> > Dojo can handle the form binding and submission automagically. If you
> > only
> > want to post a subset of the form elements, you can hand Dojo a filter
> > for
> > that.
> >
> > Perhaps I'm missing part of your use case? Can you give an example that
> > doesn't degenerate to just posting a form?
> >
> > --
> > Martin Cooper
> >
> >
> > musachy
> >>
> >> Don Brown wrote:
> >> > Hmm..ok, I see your point, however, perhaps we are pushing too much
> >> > onto the div tag.  Is there another approach which would make it
> >> > easier to grasp at a glance what we are trying to do?
> >> >
> >> > Don
> >> >
> >> > Musachy Barroso wrote:
> >> >> Suppose there is an action "foo.action" that we want to call using
> an
> >> >> ajax request, and we want to pass as a paratemer to the action the
> >> >> current value of a text input field. The jsp would be something
> like:
> >> >>
> >> >> <input type=text id="sometext">
> >> >>
> >> >> <s:div theme="ajax" id="somediv" href="foo.action"
> >> >> parameters="value={sometext}" refreshListenTopic="/refresh">
> >> >> <s:div>
> >> >>
> >> >> Now, you type "test" on the textbox, and you force the div to
> >> >> refresh; "parameters" will be expanded to "value=test", and the url
> >> >> for the request will be: "foo.action?value=test". So we can pass
> user
> >> >> entered/selected data to the action.
> >> >>
> >> >> musachy
> >> >>
> >> >> Don Brown wrote:
> >> >>> Perhaps not...could you back up and explain the use case?
> >> >>> Don
> >> >>>
> >> >>> Musachy Barroso wrote:
> >> >>>> This parameters will be evaluated by javascript on the client
> side,
> >> >>>> just before the request is made. Are we talking about the same
> >> thing?
> >> >>>>
> >> >>>> musachy
> >> >>>>
> >> >>>> Don Brown wrote:
> >> >>>>> If you are talking about the server-side tags, then yes,
you can
> >> >>>>> add parameters, but by using a <param> child tag
under the
> >> element.
> >> >>>>>
> >> >>>>> Don
> >> >>>>>
> >> >>>>> Musachy Barroso wrote:
> >> >>>>>> I was thinking in adding an attribute to the ajax tags,
> >> >>>>>> "parameters", which
> >> >>>>>> will be evaluated before the request is made, so parameters
with
> >> >>>>>> current
> >> >>>>>> values can be passed. Something like
> >> >>>>>>
> >> >>>>>> ... href="/foo.action" parameters="value={selectId}&bb=cc"
..
> >> >>>>>>
> >> >>>>>> the url for the request would be:
> >> >>>>>>
> >> >>>>>> /foo.action?value=bar&bb=cc
> >> >>>>>>
> >> >>>>>> where "bar" is the value of the element with id "selectId".
I
> >> >>>>>> find strange
> >> >>>>>> this was requested before, could there be a bug in
jira for
> this?
> >> >>>>>>
> >> >>>>>> musachy
> >> >>>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> ---------------------------------------------------------------------
> >> >>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> >>>>> For additional commands, e-mail: dev-help@struts.apache.org
> >> >>>>>
> >> >>>>>
> >> >>>>
> >> >>>>
> >> ---------------------------------------------------------------------
> >> >>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> >>>> For additional commands, e-mail: dev-help@struts.apache.org
> >> >>>>
> >> >>>>
> >> >>>
> >> >>>
> >> >>>
> >> ---------------------------------------------------------------------
> >> >>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> >>> For additional commands, e-mail: dev-help@struts.apache.org
> >> >>>
> >> >>>
> >> >>
> >> >>
> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> >> For additional commands, e-mail: dev-help@struts.apache.org
> >> >>
> >> >>
> >> >
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> > For additional commands, e-mail: dev-help@struts.apache.org
> >> >
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> For additional commands, e-mail: dev-help@struts.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message