Re: Tapestry feature request -

[Jamie <ja...@dang.com>]

Karthik, you should publish this over on the developer list.

Jamie

Karthik Abram wrote:

>I'm reposting this reply of mine for better visibility ...
>
>
>This is both a solution and a proposal. I had to do the same - except more
>generally, I wanted to be able to have get any component's html ID and tie
>it to javascript.
>
>The solution I came up with was to write an "observer" component and have
>all my components (subclassed from Base, Abstract and AbstractForm)
>implement an "Observable" interface. The idea is simple. You wrap all
>components you want to observe with the observer component. The observer
>registers itself in the request cycle under a well-known name. Observable
>components can be given html id patterns. In their rendercomponent method,
>observable components check to see if there is an observer and register
>themselves. The observer is also smart to tag a unique number (specific to
>each html id pattern). Upon registration, the observer calls an "observe"
>method that subclasses of observer override to provide specific
>funtionality. Finally, once the body of the observer has rendered, it calls
>a getJS function to generate javascript.
>
>In your case, such a solution would involve setting a pattern of "id" for
>the individual cells and the total field and having the total then use the
>id to compute the total.
>
>Now, in this regard, I do have a TAPESTRY MODIFICATION REQUEST. Actually
>two:
>
>1) MODIFY BaseComponent, AbstractComponent and AbstractForm to all be one
>interface. A form comp. should really be smart enough to know if it is being
>included in a form and not have to rely on a subclass. Here is why - I want
>to introduce a common parent class or interface for all my components. Well,
>I have to provide three implementation, one for base, abstract and abstract
>form.
>
>2) There is no mechanism, that doesn't involve the page to retain state
>between a rewind and render cycle. The request cycle's map gets cleared
>between the cycles. Why is this? Can this be modified?
>
>Also, I'd suggest the observer pattern be introduced. Cross-component
>javascript is pretty much impossible without it.
>
>-----Original Message-----
>From: news [mailto:news@sea.gmane.org]On Behalf Of bobby rullo
>Sent: Monday, April 04, 2005 6:24 PM
>To: tapestry-user@jakarta.apache.org
>Subject: Need to know ALL the form id's of a given element
>
>
>Hi,
>
>A relatively common thing you see in a web application is an automatically
>updating total field. For example you have a bunch of line items and you
>want
>the total qty, price, etc. to update automatically whenever the user changes
>a
>number.
>
>Since this is a common pattern in the app I am creating, and this is
>Tapestry, I
>thought I'd make a component. My componenet would look something like this:
>
><span jwcid="@Totaler"
>componentToTotal="ognl:components.numericFieldQuantity" />
>
>The Totaler component would create javascript that would find all the form
>fields that the componentToTotal form component rendered and total its
>values.
>
>Sounded easy to me until I realize I can't "get at" all the form element
>id's
>that a particular form component may have generated - at least I don't know
>how
>to! The cheap way to do this is pass the totaler component a string which
>would
>be the prefix of the generated form inputs, and it could just iterate
>through
>all the components of the form and find ones that started with that prefix.
>But
>that is not very tapestry-like and requires that you make sure you don't
>have
>conflicting component names....
>
>The sort of thing I was originally looking for was something like a
>component
>render listener - something I could hook into a form component and have it
>trigger every time it was rendered on a page so I could do a getName() and
>add
>it to my list of form id's....
>
>Of course if there is another way to do this I'm open to that too - unless
>it
>involves submitting to the server!
>
>Thanks in advance,
>
>Bobby
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>  
>

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