This thread has been fun I agree. Mostly I just wanted to dump out my
brewing fears of making sure the render cycle was as intuitive as can
reasonably be made possible (as I believe it to be the ever elusive
main thing that people indirectly attribute to the supposed "steep
learning curve" ) , as
On 12/21/06, D&J Gredler <[EMAIL PROTECTED]> wrote:
So basically testability and backwards compatibility. I mourn the loss of
IDE support for refactoring, reference searching, etc, but I see your point.
Thanks for clearing things up!
What kind of IDE refactoring support and reference searching
On 12/21/06, andyhot <[EMAIL PROTECTED]> wrote:
the separate annotations look cleaner to me.
i don't quite see the benefits of that enum... Also, didn't testng start
with a
single @Configuration to end up with Before/After Test/Method/Class/Suite ?
I prefer that, even though it's 8 times more!
This is an interesting thread ... we're really seeing where the convention
vs. configuration is going. And I see some people who are nervous about
convention (the name of the method) vs. configuration (annotating the
method).
On 12/20/06, Kent Tong <[EMAIL PROTECTED]> wrote:
Howard Lewis Ship
@Render(value=RenderPhase default=BEFORE)
RenderPhase: enum SETUP, BEFORE, BEFORE_TEMPLATE, BEFORE_BODY, AFTER_BODY,
AFTER_TEMPLATE, AFTER, CLEANUP
On 12/20/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote:
There probably are some very specific circumstances where you want to
make a clear delineati
Howard Lewis Ship gmail.com> writes:
> I have a feeling that in many cases, people will prefer this approach to the
> annotation approach. Again, the methods can have any visibility, any return
> type, and flexibility on parameters.
>
> Advantage for me: when training, I can just say "name you
There probably are some very specific circumstances where you want to
make a clear delineation between rendering vs.
configuration/setup/maintenance type tasks - but like I said ...this
was more just me sharing thoughts as I thought them.
I still like the general idea of condensing the (majority)
Also true... but not by default. I'm just mentioning the downsides, making
sure we're clear on the tradeoffs involved.
On 12/21/06, andyhot <[EMAIL PROTECTED]> wrote:
D&J Gredler wrote:
> So basically testability and backwards compatibility. I mourn the loss
of
> IDE support for refactoring, re
Howard Lewis Ship wrote:
> This is certainly something we can revisit. @Render plus an enum that
> defines when to invoke would work just as well as the eight? current
> seperate annotations.
the separate annotations look cleaner to me.
i don't quite see the benefits of that enum... Also, didn't
D&J Gredler wrote:
> So basically testability and backwards compatibility. I mourn the loss of
> IDE support for refactoring, reference searching, etc, but I see your
> point.
> Thanks for clearing things up!
You can always have your own base class - anyhow you like!
>
> On 12/21/06, Howard Lewis
This is certainly something we can revisit. @Render plus an enum that
defines when to invoke would work just as well as the eight? current
seperate annotations.
On 12/20/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote:
Yeah, I think this was a case of me not doing enough homework which is
why I wa
So basically testability and backwards compatibility. I mourn the loss of
IDE support for refactoring, reference searching, etc, but I see your point.
Thanks for clearing things up!
On 12/21/06, Howard Lewis Ship <[EMAIL PROTECTED]> wrote:
D&J:
POJOs go hand-in-hand with a strong testing philo
Yeah, I think this was a case of me not doing enough homework which is
why I was afraid to speak up, but I didn't mean for one method to be
re-used for different phases..More like:
@ComponentClass
public class Count
{
@Parameter
private int _start = 1;
@Parameter(required = true)
private
D&J:
POJOs go hand-in-hand with a strong testing philosophy. One of the problems
with unit testing Tapestry 4 pages and components is that you often end up
"testing" framework code you've inherited. You have to have and
understanding of internals of Tapestry in order to test your own code.
Ther
I have some thoughts on this but am a little afraid to share them as I
know I haven't invested nearly enough time thinking about it to say
very strongly that I think they are rightbut I guess I'll ramble
on anyways., heh
I think there is one very core problem with even this style of
rendering
This isn't directed specifically at this change, but...
What is the problem with having users subclass some sort of BasePage class?
It seems we're coming full circle: extend BasePage and override methods ->
annotate your methods -> "weak override" (i.e. name your methods a certain
way but don't g
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Tapestry Wiki" for
change notification.
The following page has been changed by TomClift:
http://wiki.apache.org/tapestry/SuccessStories
The comment on the change is:
made PaperCut NG image into a link
-
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Tapestry Wiki" for
change notification.
The following page has been changed by TomClift:
http://wiki.apache.org/tapestry/SuccessStories
The comment on the change is:
added entry for PaperCut NG
[
http://issues.apache.org/jira/browse/TAPESTRY-1204?page=comments#action_12460096
]
Tomoki Tsuchida commented on TAPESTRY-1204:
---
I believe this is because of the change to
org.apache.tapestry.enhance.InjectMetaWorker that took place
boolean meta values in the component descriptor does not work
-
Key: TAPESTRY-1204
URL: http://issues.apache.org/jira/browse/TAPESTRY-1204
Project: Tapestry
Issue Type: Bug
Just made a change to T5, tell me what you think:
You can now identify render phase methods by simple method name, rather than
annotation. For each render phase (SetupRender, BeginRender) there's a
corresponding method name (setupRender(), beginRender()). Effectively,
Tapestry treats methods wi
boolean.getBoolean doesn't work as expected in InjectMetaWorker
---
Key: TAPESTRY-1203
URL: http://issues.apache.org/jira/browse/TAPESTRY-1203
Project: Tapestry
Issue Type: Bug
EventListener - send custom data in the same way browser event data is sent
---
Key: TAPESTRY-1202
URL: http://issues.apache.org/jira/browse/TAPESTRY-1202
Project: Tapestry
Jesse Kuhnert wrote:
> I knowI was vaguely remembering that as I cursed myself while
> trying to fix thisGood idea! ;)
Well, don't curse yourself... it's only *my* fault that it's still an idea!
>
> On 12/20/06, andyhot <[EMAIL PROTECTED]> wrote:
>> I did write
>> http://www.nabble.com/id
I knowI was vaguely remembering that as I cursed myself while
trying to fix thisGood idea! ;)
On 12/20/06, andyhot <[EMAIL PROTECTED]> wrote:
I did write
http://www.nabble.com/ids-in-html-elements-tf2722702.html#a7593091
trying to provoke talk on this topic and come up with a uniform sol
I did write
http://www.nabble.com/ids-in-html-elements-tf2722702.html#a7593091
trying to provoke talk on this topic and come up with a uniform solution.
I still need to do http://issues.apache.org/jira/browse/TAPESTRY-1196
and then I'd consider the current solution as being bulletproof !
[EMAIL
OK, I do my best :)
Regards:
Norbi
Jesse Kuhnert írta:
Sorry for not responding sooner, I didn't want to randomly blurt
something out if it might cause someone to do work based on something
I said.
Of course I'd love to have the help of some sort of auto-generated
documentation help. My person
I'm seeing where you are going with this.
However, I'm troubled by the necessity to cast from Link to LinkImpl, and
the need for different components to know about the InAppInvocationMap.
How about if we invert things; have components pass themselves to
LinkFactory and let LinkFactory deal with
Nope, an accident.
On 12/19/06, Kent Tong <[EMAIL PROTECTED]> wrote:
Hi,
Before I committed the last time, ValidationMessages.properties was in
src/main/java and was not picked up by maven. To make the tests pass, I
moved it into src/main/resources. My question is, was it placed into
src/main/
Very interesting!!
On 12/20/06, Ron Piterman <[EMAIL PROTECTED]> wrote:
Howard Lewis Ship wrote:
> Interesting idea with the caveat that it can not be fully validated at
> compile time (all of the extra attributes will need to have default
values
> ... oh and for primtives, its very hard to dis
Howard Lewis Ship wrote:
> Interesting idea with the caveat that it can not be fully validated at
> compile time (all of the extra attributes will need to have default values
> ... oh and for primtives, its very hard to distinguish a default value
> for a
> provided value).
there is a dirty trick:
In one project we use many generic components and use the parameters of
type class alot - currenty I find there is no "good way" of passing a
class as parameter. The best I know is delegate to a method on the
component which look like:
getFooClass() { return Foo.class };
because this is "refact
[
http://issues.apache.org/jira/browse/TAPESTRY-717?page=comments#action_12459869
]
Ron Piterman commented on TAPESTRY-717:
---
There are some usecases in which one needs such an access, for me the most
important one is sharing information a
I'm working on a new release, its primary goal is better documentation.
The info comes from .jwc files and javadoc comments as well, so you can
generate documentation for annotation based components. (Although there
is a related issue: http://issues.apache.org/jira/browse/TAPESTRY-1192)
Additio
[
http://issues.apache.org/jira/browse/TAPESTRY-717?page=comments#action_12459853
]
Jesse Kuhnert commented on TAPESTRY-717:
In response to Navin,
The way that most of the enhancement workers do this is by simply injecting the
referenc
[
http://issues.apache.org/jira/browse/TAPESTRY-717?page=comments#action_12459851
]
Norbert Sándor commented on TAPESTRY-717:
-
I agree with Navin.
Besides in more complex applications I often find it necessary to access
hivemind service
[
http://issues.apache.org/jira/browse/TAPESTRY-1201?page=comments#action_12459850
]
Patrick Moore commented on TAPESTRY-1201:
-
obviously should not be a "major" issue :-) .
> tapestry-contrib depends on jboss-j2ee
> ---
tapestry-contrib depends on jboss-j2ee
--
Key: TAPESTRY-1201
URL: http://issues.apache.org/jira/browse/TAPESTRY-1201
Project: Tapestry
Issue Type: Improvement
Components: Contrib
Affects Vers
38 matches
Mail list logo
