Re: [T5]: Question about temporary properties
On 8/24/07 5:44 PM, in article
[EMAIL PROTECTED], "Josh Canfield"
<[EMAIL PROTECTED]> wrote:
>> anyway? If the loop can already figure these out, make them read-only
>> properties of the loop. Then you could reference them like ${loop_id.index}
>> or ${loop_id.value}.
>>
> That'd be nice in some cases, but there are also times when I want to
> be able to access them through my component class. I like being able
> to separate out my rendering logic from my page so that I could change
> it in one place. For instance, if you want to color rows of a table
> its nice to be able to do something like
>
> ...
>
> and let the component decide the row colouring scheme based on the
> rows position. I suppose you could access the Loop component directly
> to ask it it's position when getRowClass() is called. This leaves you
> with a pretty clean template, I suppose potentially at the expense of
> the class file...
Correct. You have two approaches:
1) Use a conditional component in the template and nothing ever touches your
page class.
2) Still have a getRowClass() in your page class, but rather than call
getSomeIndex(), it'd call getSomeLoop().getIndex(). I'd argue that the
latter is even better because it removes ambiguity. By restricting the
choice, you don't have arbitrary index properties that can be named
differently on a per class/project/developer basis. Rather, you have a
uniform approach to accessing that info. Plus, you keep static analysis
tools happy.
--
Kevin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [T5]: Question about temporary properties
> anyway? If the loop can already figure these out, make them read-only
> properties of the loop. Then you could reference them like ${loop_id.index}
> or ${loop_id.value}.
>
That'd be nice in some cases, but there are also times when I want to
be able to access them through my component class. I like being able
to separate out my rendering logic from my page so that I could change
it in one place. For instance, if you want to color rows of a table
its nice to be able to do something like
...
and let the component decide the row colouring scheme based on the
rows position. I suppose you could access the Loop component directly
to ask it it's position when getRowClass() is called. This leaves you
with a pretty clean template, I suppose potentially at the expense of
the class file...
Josh
--
--
TheDailyTube.com. Sign up and get the best new videos on the internet
delivered fresh to your inbox.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [T5]: Question about temporary properties
Well, on the one hand I guess that means it's not supported yet. But on the
other, it's nice to see that there's interest in it.
Taking it a step further, it'd be nice if you didn't even need to bind a
value and if they just became properties of the component itself. E.g., why
supply a value or an index parameter if they're likely to be read-only
anyway? If the loop can already figure these out, make them read-only
properties of the loop. Then you could reference them like ${loop_id.index}
or ${loop_id.value}.
--
Kevin
On 8/24/07 1:49 PM, in article
[EMAIL PROTECTED], "Josh Canfield"
<[EMAIL PROTECTED]> wrote:
> Interesting idea.
>
> You could look at contributing a BindingSource, call it 'variable'.
> You'd need to investigate how they are created, not sure about typing
> the values, the get/set in the Binding interface are Object so you may
> be able to get away with out worrying about it:
>
>
> ${variable:theValue}
>
>
> Look at the TapestryModule for details about adding BindingSource...
> http://tapestry.apache.org/tapestry5/tapestry-core/apidocs/src-html/org/apache
> /tapestry/services/TapestryModule.html
> (line 329)
>
> Any reason something like that couldn't work?
>
> Josh
>
> On 8/24/07, Kevin Menard <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> Now that T4 is likely to go the way of the dodo and I'm looking at a new
>> app, I'm evaluating T5 along with several other frameworks. I'm trying to
>> get some info on T5 that may help out.
>>
>> It appears that the page spec has gone away in T5. While it was optional in
>> T4, one of the things I found myself using it for was the declaration of
>> temporary properties. I did not want to pollute my page classes with the
>> temporary property used to hold a For loop's value, for example. Aside from
>> aesthetics, this would create a problem with code analyzers that would
>> inaccurately mark sections as unused. Someone would invariably delete them,
>> then the app would stop working.
>>
>> Is my only option in T5 to declare the property in the page class? Or is
>> there some other way to handle this case?
>>
>> As an aside, I even had an idea for cleaning this up in T4 [1]
>>
>> Thanks for any info,
>> Kevin
>>
>> [1] -- https://issues.apache.org/jira/browse/TAPESTRY-1694
>>
>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [T5]: Question about temporary properties
On Fri, 24 Aug 2007 14:49:39 -0300, Josh Canfield <[EMAIL PROTECTED]>
wrote:
Interesting idea.
You could look at contributing a BindingSource, call it 'variable'.
You'd need to investigate how they are created, not sure about typing
the values, the get/set in the Binding interface are Object so you may
be able to get away with out worrying about it:
${variable:theValue}
Very interesting idea!
As far as I thought about this topic, maybe a threaded service would be a
nice way to implement this, as we have to clear these variables after they
were used. Tapestry-IoC can notify thread-scoped services the thread has
finished its execution.
My only doubt is about how the prop:binding would deal with these
"untyped" values.
--
Thiago H. de Paula Figueiredo
Desenvolvedor, Instrutor e Consultor de Tecnologia
Eteg Tecnologia da Informação Ltda.
http://www.eteg.com.br
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [T5]: Question about temporary properties
Interesting idea.
You could look at contributing a BindingSource, call it 'variable'.
You'd need to investigate how they are created, not sure about typing
the values, the get/set in the Binding interface are Object so you may
be able to get away with out worrying about it:
${variable:theValue}
Look at the TapestryModule for details about adding BindingSource...
http://tapestry.apache.org/tapestry5/tapestry-core/apidocs/src-html/org/apache/tapestry/services/TapestryModule.html
(line 329)
Any reason something like that couldn't work?
Josh
On 8/24/07, Kevin Menard <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Now that T4 is likely to go the way of the dodo and I'm looking at a new
> app, I'm evaluating T5 along with several other frameworks. I'm trying to
> get some info on T5 that may help out.
>
> It appears that the page spec has gone away in T5. While it was optional in
> T4, one of the things I found myself using it for was the declaration of
> temporary properties. I did not want to pollute my page classes with the
> temporary property used to hold a For loop's value, for example. Aside from
> aesthetics, this would create a problem with code analyzers that would
> inaccurately mark sections as unused. Someone would invariably delete them,
> then the app would stop working.
>
> Is my only option in T5 to declare the property in the page class? Or is
> there some other way to handle this case?
>
> As an aside, I even had an idea for cleaning this up in T4 [1]
>
> Thanks for any info,
> Kevin
>
> [1] -- https://issues.apache.org/jira/browse/TAPESTRY-1694
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
--
TheDailyTube.com. Sign up and get the best new videos on the internet
delivered fresh to your inbox.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
