Curiosity Question

[Gregg D Bolinger <gt...@gmail.com>]

Why does Tapesty use jwcid= instead of just looking for the id attribute and 
then verfying that against the .page specification as it does for the jwcid. 
Would it be harder to catch missing components early on? Just curious.

Gregg Bolinger

Re: Curiosity Question

[Howard Lewis Ship <hl...@gmail.com>]

That works fine, until your components render inside a loop, at which
point they need new ids for each rendering (since ids names must be
unique).  This is even worse in the Portlet world, since the HTML page
will be made up of many portlets that could easily provide conflicting
ids for elements.

The framework operates, by design, in a kind of "tunnel vision", where
it can't rely on just about anything outside of the one component
actively rendering.

On 5/12/05, Preston L. Bannister <pr...@bannister.us> wrote:
> This sure feels like a mistake.
> 
> In the DOM and CSS worlds nodes can be selected by tag, class, and id.
> The Tapestry domain invents/requires yet another selector.
> 
> Personally I find this a source of much duplication.  If you have a need
> to identify an element, better to use one "id" for all worlds - CSS,
> Javascript, and Tapestry.  For elements where the id is needed only for
> Tapestry, a simple name convention could suffice to identify id's that
> should be stripped from the generated HTML.
> 
> My $0.02.
> 
> 
> Howard Lewis Ship wrote:
> > Yes, to avoid the class.
> >
> > 4.0 lets you override which attribute to look for, so you can use id
> > instead of jwcid (but then you can't set the id of your rendered
> > elements).
> 
> >>-----Original Message-----
> >>From: Gregg D Bolinger [mailto:gthought@gmail.com]
> >>Sent: Tuesday, May 10, 2005 5:48 PM
> >>
> >>Why does Tapesty use jwcid= instead of just looking for the id attribute and
> >>then verfying that against the .page specification as it does for the jwcid.
> >>Would it be harder to catch missing components early on? Just curious.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> 
> 


-- 
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind

Professional Tapestry training, mentoring, support
and project work.  http://howardlewisship.com

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

Re: Curiosity Question

["Preston L. Bannister" <pr...@bannister.us>]

This sure feels like a mistake.

In the DOM and CSS worlds nodes can be selected by tag, class, and id.
The Tapestry domain invents/requires yet another selector.

Personally I find this a source of much duplication.  If you have a need 
to identify an element, better to use one "id" for all worlds - CSS, 
Javascript, and Tapestry.  For elements where the id is needed only for 
Tapestry, a simple name convention could suffice to identify id's that 
should be stripped from the generated HTML.

My $0.02.


Howard Lewis Ship wrote:
> Yes, to avoid the class.
> 
> 4.0 lets you override which attribute to look for, so you can use id
> instead of jwcid (but then you can't set the id of your rendered
> elements).

>>-----Original Message-----
>>From: Gregg D Bolinger [mailto:gthought@gmail.com]
>>Sent: Tuesday, May 10, 2005 5:48 PM
>>
>>Why does Tapesty use jwcid= instead of just looking for the id attribute and
>>then verfying that against the .page specification as it does for the jwcid.
>>Would it be harder to catch missing components early on? Just curious.


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

Re: Curiosity Question

[Howard Lewis Ship <hl...@gmail.com>]

Yes, to avoid the class.

4.0 lets you override which attribute to look for, so you can use id
instead of jwcid (but then you can't set the id of your rendered
elements).

On 5/10/05, Karthik Abram <ka...@neovera.com> wrote:
> 
> Won't the id field clash with html ID??
> 
> -----Original Message-----
> From: Gregg D Bolinger [mailto:gthought@gmail.com]
> Sent: Tuesday, May 10, 2005 5:48 PM
> To: Tapestry users
> Subject: Curiosity Question
> 
> Why does Tapesty use jwcid= instead of just looking for the id attribute and
> then verfying that against the .page specification as it does for the jwcid.
> Would it be harder to catch missing components early on? Just curious.
> 
> Gregg Bolinger
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> 
> 


-- 
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind

Professional Tapestry training, mentoring, support
and project work.  http://howardlewisship.com

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

RE: Curiosity Question

[Karthik Abram <ka...@neovera.com>]

Won't the id field clash with html ID??

-----Original Message-----
From: Gregg D Bolinger [mailto:gthought@gmail.com]
Sent: Tuesday, May 10, 2005 5:48 PM
To: Tapestry users
Subject: Curiosity Question


Why does Tapesty use jwcid= instead of just looking for the id attribute and
then verfying that against the .page specification as it does for the jwcid.
Would it be harder to catch missing components early on? Just curious.

Gregg Bolinger


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