Curiosity Question

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Curiosity Question

Gregg D Bolinger
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
Reply | Threaded
Open this post in threaded view
|

RE: Curiosity Question

Karthik Abram

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

-----Original Message-----
From: Gregg D Bolinger [mailto:[hidden email]]
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Curiosity Question

Howard Lewis Ship
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 <[hidden email]> wrote:

>
> Won't the id field clash with html ID??
>
> -----Original Message-----
> From: Gregg D Bolinger [mailto:[hidden email]]
> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Curiosity Question

Preston L. Bannister
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:[hidden email]]
>>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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Curiosity Question

Howard Lewis Ship
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 <[hidden email]> 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:[hidden email]]
> >>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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
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: [hidden email]
For additional commands, e-mail: [hidden email]