LinkSubmit (was RE: New Table components [+ VOTE])

[Richard Lewis-Shell <rl...@mac.com>]

mb - _both_ of those LinkSubmit issues sound like bugs to me, and your
analysis of the latter seems spot on...

R

-----Original Message-----
From: Mindbridge [mailto:mindbridgeweb@yahoo.com] 
Sent: Tuesday, 26 August 2003 9:14 a.m.
To: Tapestry development
Subject: Re: New Table components [+ VOTE]


Hi guys,

    Sorry for the delay with this, but I finally had time to go through some
more extensive tests before I checked things in. Needless to say, I've
discovered some problems :)

    First of all, just a note of something that I found last week -- if a
LinkSubmit is used in a form, the form _must not_ contain an <input> with
the name 'submit'. If it does, the javascript gets confused and blows up
when form.submit() is invoked with the error "Object doesn't support this
property or method". In other words, using something like <span
jwcid="submit@Submit"/> and a LinkSubmit in the same form is a no-no. I lost
about 2 hours trying to determine this, perhaps we need to document it well.
One interesting point -- since Submit and LinkSubmit could be located in
different components, but in the same form, perhaps forbidding a component
id of 'submit' for the any of the <input> components would be a good idea?

    One other thing: LinkSubmit has the following javascript:

function submitLink(form, elementId) {
  form._linkSubmit.value = elementId;
  if (form.onsubmit == null || form.onsubmit())
    form.submit();
}

    This allows the following to occur: a LinkSubmit is pressed, the
_linkSubmit field's value is changed, but the onsubmit() method of the form
returns false (e.g. due to a client-side validator) and the form is not
submitted. If the user then clicks on a Submit button and the form is
submitted, the LinkSubmit listener is invoked sinc _linkSubmit was set
earlier, even though it was not really the cause of the event.  A quick fix
would be something like this:

function submitLink(form, elementId) {
  if (form.onsubmit == null || form.onsubmit()) {
    form._linkSubmit.value = elementId;
    form.submit();
  }
}

Please let me know if I am missing something, otherwise I will add a bug and
fix it.


    Back to TableFormPages -- this does not fully work at the moment. To
make it work, I need either FormConditional or delayed listener invocation
(and ideally both :). Howard, you mentioned that you are going to work on
FormConditional. When do you plan to check it in? Please let me know if I
can help in any way.

    With respect to the delayed listener invocation: we have ruled out
modifying the default behaviour in 3.0, which pretty much rules it out
completely (see discussion on backward compatibility). One alternative that
is fully backward-compatible (and hence would not cause backward-compatible
problems in future versions) and does not affect existing code is to add
another parameter to the Form components in addition to 'listener', say
'delayedListener'. That parameter will contain a listener that will be
invoked after the rewind but before the Form listener. The user of a form
component could define either or both a listener and a delayedListener -- 
they will be invoked, but at a different times. Two questions here to vote
on:

- Do you agree with this approach as a solution to the problem? What would
be a good alternative otherwise? My personal opinion is obviously 'yes'.

- Should this wait until 3.1 given that we are in the beta cycle? I would
normally say 'wait', but this is a slightly special case -- there is a lot
of interest in this shown on the user list, it is demonstratably very
useful, it does not affect current code, and its late addition could be
compensated with special peer-review and targetted testing. In other words,
I am for additing it in the next beta, as long as at least TWO additional
committers express interest in performing a full code review and testing of
the changes. If there is no such commitment, I would vote strongly for
leaving it for 3.1.

Please vote :)

Best regards,
-mb


----- Original Message ----- 
From: "David Solis" <ds...@legosoft.com.mx>
To: "'Tapestry development'" <ta...@jakarta.apache.org>
Sent: Saturday, August 23, 2003 7:25 PM
Subject: RE: New Table components


> Please check your components in, I'd like to test them.
>
> Regards
>
> D.
>
> > -----Original Message-----
> > From: Mindbridge [mailto:mindbridgeweb@yahoo.com]
> > Sent: Saturday, August 23, 2003 8:49 AM
> > To: Tapestry development
> > Subject: New Table components
> >
> > Hi,
> >
> >     I have made a few new Table components for work in a form. The 
> > equivalent of TableRows is TableFormRows and uses ListEdit instead 
> > of Foreach, which should make it more or less immune to StaleLink
> exceptions.
> > There are also TableFormPages and a new standard rendition of the
> column
> > headers that use LinkSubmit instead of DirectLink. They allow, for 
> > example, to select some items in the list using checkboxes, go to
> another
> > page, select some more, come back to the original page, and still
> remember
> > the originally selected items.
> >
> >     I would like to check those in, but we are in the beta cycle, so 
> > I thought I should notify you first. Those are all new components in
> Contrib
> > (not the framework), there are no changes in the old ones, so I 
> > think
> that
> > should be okay.
> >
> >     One other little thing -- perhaps ListEdit could have another
> > (optinal) parameter, an interface that converts the iterated item 
> > into
> the
> > object that will be stored into the corresponding Hidden field. This
> would
> > allow iterating over non-serializable objects, getting their primary
> key,
> > storing that, and the recovering the object during the rewind. There
> are
> > workarounds, of course (e.g. registering a Squeeze Adaptor for that 
> > object), but it seems to me it will greatly simplify the coding in
> some
> > situations and will decrease the size of the data that is passed 
> > back
> and
> > forth. Howard, you mentioned adding ListConditional to Contrib, does
> it
> > make sense adding this now as well? It is backward compatible.
> >
> > Best regards,
> > -mb
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org