You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Howard Lewis Ship <hl...@gmail.com> on 2004/08/01 15:54:45 UTC
Re: Component naming
You mean form.getElementName()?
Dangerous. If a Form contains components A and components B and those
components contain components A1, A2, B1 and B2 then the naming of the
B1 and B2 components can changed if components inside A (A1, A2) are
added or changed. Then you get into the issue with loops.
The CSS thing is getting to be an annoynance, but could be solved by
having a parallel to Body/Script.
I think what would be nice would be to streamline JavaScript
generation. What about an InlineScript component that had most of the
power of the Script component without using an external script file?
What if we provided a suite of useable scripts (wrapped as components)
in the contrib library?
On Sat, 31 Jul 2004 13:53:34 -0400, Harish Krishnaswamy
<hk...@comcast.net> wrote:
> What are the perils of relaxing the component naming strategy?
>
> Currently the component naming is undefined. This leads to complexities
> with javascript, CSS and such. Why not define a component naming
> strategy? This will certainly simplify things quite a bit, right?
>
> -Harish
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
HEAD stability
Posted by Howard Lewis Ship <hl...@gmail.com>.
All tests pass, so that's good. However, I'm not sure if it builds ...
I've been doing all my work from Eclipse.
The frameworks & etc. builds, but not the unit test suite. I think
EasyMock needs to be added.
I'm planning on re-working the Tapestry build to work using HiveMind
Ant scripts. That will support automated download of dependencies!
Perhaps I'll have time this weekend.
On Sun, 01 Aug 2004 23:14:21 -0400, Harish Krishnaswamy
<hk...@comcast.net> wrote:
> BTW, is the cvs trunk in a stable state that we can start using and
> modifying?
>
> -Harish
>
>
>
> Harish Krishnaswamy wrote:
>
> > It is certainly better to not have to think about component naming.
> > InlineScript sounds very appealing although I am not exactly sure what
> > you mean by it. Do you mean to simply embed the script contents in the
> > template? And yes, at the very least we definitely need something
> > equivalent to the script for css.
> >
> > -Harish
> >
> > Howard Lewis Ship wrote:
> >
> >> You mean form.getElementName()?
> >>
> >> Dangerous. If a Form contains components A and components B and those
> >> components contain components A1, A2, B1 and B2 then the naming of the
> >> B1 and B2 components can changed if components inside A (A1, A2) are
> >> added or changed. Then you get into the issue with loops.
> >>
> >> The CSS thing is getting to be an annoynance, but could be solved by
> >> having a parallel to Body/Script.
> >>
> >> I think what would be nice would be to streamline JavaScript
> >> generation. What about an InlineScript component that had most of the
> >> power of the Script component without using an external script file?
> >> What if we provided a suite of useable scripts (wrapped as components)
> >> in the contrib library?
> >>
> >> On Sat, 31 Jul 2004 13:53:34 -0400, Harish Krishnaswamy
> >> <hk...@comcast.net> wrote:
> >>
> >>
> >>> What are the perils of relaxing the component naming strategy?
> >>>
> >>> Currently the component naming is undefined. This leads to complexities
> >>> with javascript, CSS and such. Why not define a component naming
> >>> strategy? This will certainly simplify things quite a bit, right?
> >>>
> >>> -Harish
> >>>
> >>> ---------------------------------------------------------------------
> >>> 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
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Component naming
Posted by Harish Krishnaswamy <hk...@comcast.net>.
BTW, is the cvs trunk in a stable state that we can start using and
modifying?
-Harish
Harish Krishnaswamy wrote:
> It is certainly better to not have to think about component naming.
> InlineScript sounds very appealing although I am not exactly sure what
> you mean by it. Do you mean to simply embed the script contents in the
> template? And yes, at the very least we definitely need something
> equivalent to the script for css.
>
> -Harish
>
> Howard Lewis Ship wrote:
>
>> You mean form.getElementName()?
>>
>> Dangerous. If a Form contains components A and components B and those
>> components contain components A1, A2, B1 and B2 then the naming of the
>> B1 and B2 components can changed if components inside A (A1, A2) are
>> added or changed. Then you get into the issue with loops.
>>
>> The CSS thing is getting to be an annoynance, but could be solved by
>> having a parallel to Body/Script.
>>
>> I think what would be nice would be to streamline JavaScript
>> generation. What about an InlineScript component that had most of the
>> power of the Script component without using an external script file?
>> What if we provided a suite of useable scripts (wrapped as components)
>> in the contrib library?
>>
>> On Sat, 31 Jul 2004 13:53:34 -0400, Harish Krishnaswamy
>> <hk...@comcast.net> wrote:
>>
>>
>>> What are the perils of relaxing the component naming strategy?
>>>
>>> Currently the component naming is undefined. This leads to complexities
>>> with javascript, CSS and such. Why not define a component naming
>>> strategy? This will certainly simplify things quite a bit, right?
>>>
>>> -Harish
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Component naming
Posted by Harish Krishnaswamy <hk...@comcast.net>.
It is certainly better to not have to think about component naming.
InlineScript sounds very appealing although I am not exactly sure what
you mean by it. Do you mean to simply embed the script contents in the
template? And yes, at the very least we definitely need something
equivalent to the script for css.
-Harish
Howard Lewis Ship wrote:
>You mean form.getElementName()?
>
>Dangerous. If a Form contains components A and components B and those
>components contain components A1, A2, B1 and B2 then the naming of the
>B1 and B2 components can changed if components inside A (A1, A2) are
>added or changed. Then you get into the issue with loops.
>
>The CSS thing is getting to be an annoynance, but could be solved by
>having a parallel to Body/Script.
>
>I think what would be nice would be to streamline JavaScript
>generation. What about an InlineScript component that had most of the
>power of the Script component without using an external script file?
>What if we provided a suite of useable scripts (wrapped as components)
>in the contrib library?
>
>On Sat, 31 Jul 2004 13:53:34 -0400, Harish Krishnaswamy
><hk...@comcast.net> wrote:
>
>
>>What are the perils of relaxing the component naming strategy?
>>
>>Currently the component naming is undefined. This leads to complexities
>>with javascript, CSS and such. Why not define a component naming
>>strategy? This will certainly simplify things quite a bit, right?
>>
>>-Harish
>>
>>---------------------------------------------------------------------
>>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
Re: Component naming
Posted by Harish Krishnaswamy <hk...@comcast.net>.
If you have eclipse its very simple to create a patch, simply
right-click on the resource and select team->create patch. I am sure
other IDEs have simple ways too. Then open a Bugzilla ticket and attach
the patch.
-Harish
Filip S. Adamsen wrote:
>I actually created a @Style component and integrated it with a custom @Shell
>component yesterday. It worked. There are some minor issues, though:
>
>1. My @Style component only allows you to include an external style sheet,
>but has no support for inline CSS. This could easily be added, though. I
>guess the body of the @Style could be used for that. The question is: do we
>need that piece of functionality?
>
>2. In order for the style sheet links to be written in the <head/> section,
>I had to make the @Shell buffer it's body the way @Body does. I am not sure
>if there any performance problems associated with that, but I doubt it.
>
>3. The close cooperation between @Style and @Shell would of course require
>all @Style components to (ultimately) be nested in a @Shell, but I suppose
>that this is not a problem, since most people use the @Shell component
>anyway.
>
>4. Currently, the @Shell has two references to style sheets. Add to this the
>style sheets added by the @Script, and you have three sources for style
>sheets. In my current implementation I just write the links to the style
>sheets from the @Style components and let the @Shell do its usual thing.
>Some refactoring might be appropriate here.
>
>5. My implementation uses assets to represent style sheets, but that should
>perhaps be changed to use a String like the @Script component?
>
>6. I have no clue about how to submit a patch with my changes - I'm just a
>high school student toying around with some web development in my spare
>time. But if you are interested, we could work something out.
>
>Comments are welcome.
>
>-Filip S. Adamsen
>
>-----Original Message-----
>From: Howard Lewis Ship [mailto:hlship@gmail.com]
>Sent: Sunday, August 01, 2004 3:55 PM
>To: Tapestry development
>Subject: Re: Component naming
>
>[...]
>
>The CSS thing is getting to be an annoynance, but could be solved by
>having a parallel to Body/Script.
>
>[...]
>
>
>
>---------------------------------------------------------------------
>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
RE: Component naming
Posted by "Filip S. Adamsen" <fi...@stubkjaer-adamsen.dk>.
I actually created a @Style component and integrated it with a custom @Shell
component yesterday. It worked. There are some minor issues, though:
1. My @Style component only allows you to include an external style sheet,
but has no support for inline CSS. This could easily be added, though. I
guess the body of the @Style could be used for that. The question is: do we
need that piece of functionality?
2. In order for the style sheet links to be written in the <head/> section,
I had to make the @Shell buffer it's body the way @Body does. I am not sure
if there any performance problems associated with that, but I doubt it.
3. The close cooperation between @Style and @Shell would of course require
all @Style components to (ultimately) be nested in a @Shell, but I suppose
that this is not a problem, since most people use the @Shell component
anyway.
4. Currently, the @Shell has two references to style sheets. Add to this the
style sheets added by the @Script, and you have three sources for style
sheets. In my current implementation I just write the links to the style
sheets from the @Style components and let the @Shell do its usual thing.
Some refactoring might be appropriate here.
5. My implementation uses assets to represent style sheets, but that should
perhaps be changed to use a String like the @Script component?
6. I have no clue about how to submit a patch with my changes - I'm just a
high school student toying around with some web development in my spare
time. But if you are interested, we could work something out.
Comments are welcome.
-Filip S. Adamsen
-----Original Message-----
From: Howard Lewis Ship [mailto:hlship@gmail.com]
Sent: Sunday, August 01, 2004 3:55 PM
To: Tapestry development
Subject: Re: Component naming
[...]
The CSS thing is getting to be an annoynance, but could be solved by
having a parallel to Body/Script.
[...]
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org