P.S. I think this has laid the knowledge groundwork needed to map out direct
component renders
finally, but now that I've noticed Howard has started the ever-so-delicate
stage of handling form
logic I may just wait and see what I can pilfer from his hard earned
thoughts instead. ;)

On 11/6/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote:

Oh how stupid of me. Guess which component is probably best suited for
carrying
around important state information? Form :)

The only thing that matters during rewind is making sure the ids generated
are the same as what
were generated when it was first displayed, if they change drastically on
the non rewind cycle it won't
matter. So...Problem solved I think.

On 11/6/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote:
>
> Hmmm....Maybe we aren't on the same page.
>
> I've solved the getting of client ids before / during (for the most
> part), but the after render part has me a little
> concerned.
>
> A big reason why tapestry scales so well is in how it handles transient
> properties, so I'm not sure
> introducing some of these things for the sake of easier use necessarily
> makes for a better
> solution...I could see changing the _clientId property to be generated
> on each render and left "in tact" being
> generally ok though. Form does it already right? (In fact, we can
> probably eliminate this _name
> property from Form altogether now that _clientId and _name generally
> always equal for any form
> component)
>
> As for "regions" of a page that are being refreshed - this is hopefully
> already being handled by
> the framework "as is" ? Because of the b0rken way IE handles event
> connections we really
> don't have a choice in the matter. (Meaning doing node.innerHTML works
> just fine in moz without
> having to re-wire anything but not at all in IE...and you'll actually
> end up with a huge number of phantomed
> references lying around in ie that will never get cleaned up if you
> don't specifically disconnect them
> before doing that...hooray for leaky abstractions. It's good to be
> reminded of all the COM running things
> to keep us honest.)
>
> On 11/6/06, andyhot < [EMAIL PROTECTED]> wrote:
> >
> > Jesse Kuhnert wrote:
> > > Yeah, the only problem with that is forms are rewound "directly", so
> > > other
> > > forms
> > > won't even be around at the time of rewind.
> > >
> > > No solution? Of course there is, somewhere.. ;) We don't really have
> > a
> > > choice I think, seeing
> > > as how no one else is going to do it for us. I could always pull out
> > my
> > > 128bit uuid stuff from
> > > old jini days past, but that seems a little brute force for
> > something
> > > like
> > > this.
> >
> > ok, let me then define what's the problem i have in mind. Perhaps
> > we're
> > really trying to
> > solve slightly different things:
> > - unique ids in a page
> > - after partial refresh all ids in page remain unique
> > - elements contained in a refreshed fragment that already existed in
> > the
> > initial
> > page should retain the same id.
> > - ability to get (client-side) id of a tapestry component ( after or
> > even before that
> > component has rendered).
> >
> > The first 2 are straightforward.
> > The 3rd is needed so that user code that works on a page ( one that
> > perhaps does dojo.byId('xxx') )
> > continues to work after the refresh.
> > The 4th is for allowing users to interact with stuff we/they generate.
> >
> >
> > >
> > > On 11/5/06, andyhot <[EMAIL PROTECTED]> wrote:
> > >>
> > >> Jesse Kuhnert wrote:
> > >> > I think I have a solution in the works to solve this "once and
> > for
> > >> > all"..Spent the majority of the day hacking around with things
> > and
> > >> > finally
> > >> > "get it" from an overarching perspective.
> > >> >
> > >> > Your namespacing of the form idea is a good one, but I don't
> > think it
> > >> > will
> > >> > be completely reliable either if a few forms are involved in a
> > page
> > >> > that sometimes render and sometimes don't.
> > >>
> > >> Well, the idea was that we'd go on and call renderIdAttribute on
> > all
> > >> those
> > >> forms even if they're not to be rendered.
> > >> Also thought of using the page-level allocator (instead of the one
> > >> provided by FormSupport)
> > >> but it actually fails worse for similar reasons.
> > >>
> > >> Anyway, i'm eager to see your solution...
> > >>
> > >> Hope you can prove me wrong cause I currently think that there's no
> > >> clean, transparent and global solution to this.
> > >> I feel there's always gonna be a sub-sub-sub-case that will fail.
> > >> But perhaps this is not that bad... at least if users are aware of
> > what
> > >> is happening (and how to deal with it).
> > >>
> > >>
> > >>
> > >> >
> > >> > I don't know when I'll be done with the changes but hopefully
> > it'll be
> > >> > today
> > >> > / tomorrow- ish.
> > >> >
> > >> > On 11/5/06, [EMAIL PROTECTED] < [EMAIL PROTECTED]> wrote:
> > >> >>
> > >> >> Author: andyhot
> > >> >> Date: Sun Nov  5 07:54:57 2006
> > >> >> New Revision: 471451
> > >> >>
> > >> >> URL: http://svn.apache.org/viewvc?view=rev&rev=471451
> > >> >> Log:
> > >> >> namespace the id of each form element with the id of the current
> > >> form...
> > >> >> resovles TAPESTRY-1131
> > >> >>
> > >> >> Modified:
> > >> >>
> > >> >>
> > >> >>
> > >>
> > 
tapestry/tapestry4/branches/4.1.1-clientIds/tapestry-framework/src/java/org/apache/tapestry/form/Form.java
> > >>
> > >> >>
> > >> >>
> > >> >>
> > >> >>
> > >>
> > 
tapestry/tapestry4/branches/4.1.1-clientIds/tapestry-framework/src/java/org/apache/tapestry/form/FormSupportImpl.java
> > >>
> > >> >>
> > >> >>
> > >> >> Modified:
> > >> >>
> > >>
> > 
tapestry/tapestry4/branches/4.1.1-clientIds/tapestry-framework/src/java/org/apache/tapestry/form/Form.java
> > >>
> > >> >>
> > >> >> URL:
> > >> >>
> > >> 
http://svn.apache.org/viewvc/tapestry/tapestry4/branches/4.1.1-clientIds/tapestry-framework/src/java/org/apache/tapestry/form/Form.java?view=diff&rev=471451&r1=471450&r2=471451
> >
> > >>
> > >> >>
> > >> >>
> > >> >>
> > >>
> > 
==============================================================================
> > >>
> > >> >>
> > >> >> ---
> > >> >>
> > >>
> > 
tapestry/tapestry4/branches/4.1.1-clientIds/tapestry-framework/src/java/org/apache/tapestry/form/Form.java
> > >>
> > >> >>
> > >> >> (original)
> > >> >> +++
> > >> >>
> > >>
> > 
tapestry/tapestry4/branches/4.1.1-clientIds/tapestry-framework/src/java/org/apache/tapestry/form/Form.java
> > >>
> > >> >>
> > >> >> Sun Nov  5 07:54:57 2006
> > >> >> @@ -193,6 +193,9 @@
> > >> >>
> > >> >>          if (isRewinding())
> > >> >>          {
> > >> >> +            // even if we're rewinding, make sure we 'train'
> > the
> > >> >> idallocator.
> > >> >> +            renderIdAttribute(writer, cycle);
> > >> >> +
> > >> >>              String submitType = _formSupport.rewind();
> > >> >>
> > >> >>              IActionListener listener =
> > findListener(submitType);
> > >> >>
> > >> >> Modified:
> > >> >>
> > >>
> > 
tapestry/tapestry4/branches/4.1.1-clientIds/tapestry-framework/src/java/org/apache/tapestry/form/FormSupportImpl.java
> >
> > >>
> > >> >>
> > >> >> URL:
> > >> >>
> > >>
> > 
http://svn.apache.org/viewvc/tapestry/tapestry4/branches/4.1.1-clientIds/tapestry-framework/src/java/org/apache/tapestry/form/FormSupportImpl.java?view=diff&rev=471451&r1=471450&r2=471451
> > >>
> > >> >>
> > >> >>
> > >> >>
> > >>
> > 
==============================================================================
> > >>
> > >> >>
> > >> >> ---
> > >> >>
> > >>
> > 
tapestry/tapestry4/branches/4.1.1-clientIds/tapestry-framework/src/java/org/apache/tapestry/form/FormSupportImpl.java
> >
> > >>
> > >> >>
> > >> >> (original)
> > >> >> +++
> > >> >>
> > >>
> > 
tapestry/tapestry4/branches/4.1.1-clientIds/tapestry-framework/src/java/org/apache/tapestry/form/FormSupportImpl.java
> >
> > >>
> > >> >>
> > >> >> Sun Nov  5 07:54:57 2006
> > >> >> @@ -393,7 +393,7 @@
> > >> >>
> > >> >>          String filteredId =
> > TapestryUtils.convertTapestryIdToNMToken
> > >> >> (baseId);
> > >> >>
> > >> >> -        String result =
> > _elementIdAllocator.allocateId(filteredId);
> > >> >> +        String result =
> > _elementIdAllocator.allocateId(filteredId +
> > >> >> "_" +
> > >> >> _form.getClientId());
> > >> >>
> > >> >>          if (_rewinding)
> > >> >>          {
> > >> >>
> > >> >>
> > >> >>
> > >> >
> > >> >
> > >>
> > >>
> > >> --
> > >> Andreas Andreou - [EMAIL PROTECTED] - http://andyhot.di.uoa.gr
> > >> Tapestry / Tacos developer
> > >> Open Source / J2EE Consulting
> > >>
> > >>
> > >>
> > ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> > >> For additional commands, e-mail: [EMAIL PROTECTED]
> > >>
> > >>
> > >
> > >
> >
> >
> > --
> > Andreas Andreou - [EMAIL PROTECTED] - http://andyhot.di.uoa.gr
> > Tapestry / Tacos developer
> > Open Source / J2EE Consulting
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> --
> Jesse Kuhnert
> Tapestry/Dojo/(and a dash of TestNG), team member/developer
>
> Open source based consulting work centered around
> dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
>



--
Jesse Kuhnert
Tapestry/Dojo/(and a dash of TestNG), team member/developer

Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com




--
Jesse Kuhnert
Tapestry/Dojo/(and a dash of TestNG), team member/developer

Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com

Reply via email to