You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Matt Welch <ma...@welchkin.net> on 2005/11/15 05:13:44 UTC

Component Specification

I'm just getting into Tapestry and while I like many of the concepts,
I'm finding it to be a little complex. Here's an example. It's my
understanding that specifying components for you pages via annotation
is new to Tapestry 4.0. I'm a fan of annotations however, in this case
they seem a little clumsy. Here's an example from my adaptation of the
tutorial I'm following (Kent Tong's Enjoying Web Development with
Tapestry):


@Component(
	id="productsLoop",
	type="For",
	bindings={
			"source=products",
			"value=currentProduct",
			"element=literal:tr"
			}
)
public abstract IComponent getProductsFor();


That's how I declared a For component for the eStore tutorial. I guess
that's really not so bad and my IDE keep the indentation clean so that
it's not too hard to follow, but to be honest, what I was kind of
expecting was something a little more code intensive rather than XML
or annotation intensive. For instance, if the BasePage or AbstractPage
had a method like addPageComponent() then in some kind of
intialization method or perhaps the contstructor I might do something
like:


{
    For productsLoop = new For();
    products.setId("productsLoop");
    productsLoop.setSource(getProducts());
    productsLoop.setValue(getCurrentProduct());
    productsLoop.setElement("tr");
    addPageComponent(productsLoop);
}


I'm guessing that this alternate way of doing things doesn't exist
since I haven't seen any tutorials or examples that show anything like
that. Has anyone ever tried to do something like that or would there
be drastic changes to core framework needed?

Again, I'm pretty new to Tapestry so it may be that I'll get used to
such heavy annotations/XML in time, so take this for what it is: a
newb's first impressions.

Matt Welch

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


Re: Component Specification

Posted by Alan Chandler <al...@chandlerfamily.org.uk>.
On Tuesday 15 Nov 2005 04:13, Matt Welch wrote:
> I'm just getting into Tapestry and while I like many of the concepts,
> I'm finding it to be a little complex. Here's an example. It's my
> understanding that specifying components for you pages via annotation
> is new to Tapestry 4.0. I'm a fan of annotations however, in this case
> they seem a little clumsy. Here's an example from my adaptation of the
> tutorial I'm following (Kent Tong's Enjoying Web Development with
> Tapestry):
>
>
> @Component(
> 	id="productsLoop",
> 	type="For",
> 	bindings={
> 			"source=products",
> 			"value=currentProduct",
> 			"element=literal:tr"
> 			}
> )
> public abstract IComponent getProductsFor();

I read some of the answers to your question, and although they were all 
correct, it seemed to me didn't help you as a newbie into tapestry figure out 
what to do.

I assume with the above example, you are refering to a bit in your html 
template where you have done

<span jwcid="productsLoop">
...
</span>

But you could just have easily done

<tr jwcid="@For" source="ognl:products" value="ognl:currentProduct">
...
</tr> 

(you could put this id in front of @For if you want - but if you leave it out 
a default is created for you).  No special java needed (although you will 
have to provide the getProducts method and an abstract method for  
getcurrentProduct within the java class that represents the page.

As youpointed out, if you are unhappy having this logic in your html template 
(because you want to separate out the responsibilities) then put xml into 
your .page file that does the same job.

>
>
> That's how I declared a For component for the eStore tutorial. I guess
> that's really not so bad and my IDE keep the indentation clean so that
> it's not too hard to follow, but to be honest, what I was kind of
> expecting was something a little more code intensive rather than XML
> or annotation intensive. For instance, if the BasePage or AbstractPage
> had a method like addPageComponent() then in some kind of
> intialization method or perhaps the contstructor I might do something
> like:
>
>
> {
>     For productsLoop = new For();
>     products.setId("productsLoop");
>     productsLoop.setSource(getProducts());
>     productsLoop.setValue(getCurrentProduct());
>     productsLoop.setElement("tr");
>     addPageComponent(productsLoop);
> }
>

I must admit having got to this bit I am confused as to what you are trying to 
do.

You seem to be mixing up using a component in a page that already exists in 
the framework - the For component in this case -  which is the way I answered 
the bit above, with declaring your own component to do something for you 
(which them makes use of others components and its own logic.


If you want to see the code intensive part of a component, this is one I made 
for my application - its aim is to output details about a person.  Its called 
(in the syntax used above) from the page as follows

<span jwcid="father@Person" label="Father" person="ognl:person.father"/>

The java, using anotations declares the component and two parameters

===========================================
package uk.org.chandlerfamily.tapestry.components; 
 
/*Copyright (c) 2005 Alan Chandler, licenced under the GPL (see LICENCE.txt 
file in META-INF directory)*/ 
 
import org.apache.tapestry.annotations.*; 
import org.apache.tapestry.BaseComponent; 
import org.apache.tapestry.IPage; 
 
import uk.org.chandlerfamily.sqlmap.famtree.PersonSummary; 
import uk.org.chandlerfamily.tapestry.famtree.Edit; 
import uk.org.chandlerfamily.tapestry.interfaces.*; 
 
@ComponentClass 
public abstract class Person extends BaseComponent { 
 
	@Parameter 
	public abstract PersonSummary getPerson(); 
	 
	@Parameter 
	public abstract String getLabel(); 
 
	@InjectPage("Edit") 
	public abstract Edit getEditPage(); 
	 
	public IPage doEdit(int personId) { 
	    Edit edit = getEditPage(); 
	    edit.setPersonId(personId); 
	    edit.setFunction(Function.EDIT); 
	    return edit; 
	} 
	 
}
==========================================

and has an html template with it

<!-- Copyright (c) 2005 Alan Chandler, licenced under the GPL (see LICENCE.txt 
file in META-INF directory) -->
<span jwcid="@If" condition="ognl:person != null">
<table class="person">

<span jwcid="@If" condition="ognl:label != null">
<tr><td id="type" class="label"><span jwcid="@Insert" 
value="ognl:label">Wife</span></td></tr>
</span>

<tr>
<td class="name" id="forename"><a jwcid="@DirectLink" 
listener="listener:doEdit" parameters="ognl:person.id"><span jwcid="@Insert" 
value="ognl:person.forename">Heather</span></a></td>
<td class="name" id="surname"><a jwcid="@DirectLink" 
listener="listener:doEdit" parameters="ognl:person.id"><span 
jwcid="@Insert"value="ognl:person.surname">Hale</span></a></td>
<td class="date"><span jwcid="@Insert" value="ognl:person.DOB">~May 
2005</span></td>
<td class="sex"><span jwcid="@Insert" value="ognl:person.gender">F</span></td>
</tr>
</table>
</span>




>
> I'm guessing that this alternate way of doing things doesn't exist
> since I haven't seen any tutorials or examples that show anything like
> that. Has anyone ever tried to do something like that or would there
> be drastic changes to core framework needed?

Puzzled as what you are trying to achieve that wants this massive change

>
> Again, I'm pretty new to Tapestry so it may be that I'll get used to
> such heavy annotations/XML in time, so take this for what it is: a
> newb's first impressions.

As a newbie myself starting directly with Tapestry 4, I found it strange that 
much of the documentation stems from Tapestry 3 where you HAD to HAVE 
component and page specifications in XML.  I started off trying very hard to 
avoid any, and built most of my code without them.  But then I discovered 
that it was often easier to build a small XML file for a specification of a 
component than do the java instead, so I now have a mixture of both.  If I 
don't need java I use the xml specification - if I need java (for instance in 
the above example to load the Edit Page, and pass it a parameter) then I use 
annotations and don't bother with the specification file.



-- 
Alan Chandler
http://www.chandlerfamily.org.uk
Open Source. It's the difference between trust and antitrust.

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


Re: Component Specification

Posted by Jesse Kuhnert <jk...@gmail.com>.
I tried so hard to rationalize what wicket was doing so that I could
try playing with it but it just didn't make sense. All of those pretty
web pages/blogs couldn't hide what they had done....

Which, from what I've read/seen is try to create a "clean and simple"
way to write web-apps, from an almost naive swing-based point of view.
What they failed to realise is that you only have to do new JPanel(),
panel.add(new ComponentBlahBlah) because that's the only medium
available...There is no html. And yet with all of this simplicity
someone made the gargantuine mistake of ignoring all of that html that
people still had to write. So yes, wicket is incredibly simple to use.
But not the good kind, the writing and debugging 30 lines of assembly
to paint a single line across your screen kind.

Tapestry on the other hand looks more like swing than wicket does to
me, only the driving force behind it hasn't blindly ignored the fact
that the rendering environment is based around html and so has
provided lots of nice ways to define things naturally this way.

Still though, there is so much more potential....If only there was a
way to get at the source, I think Tapestry could expose JSF/Wicket/etc
for the flawed architectures they are through a few simple little
enhancements to make things just sort of "work" the way you'd like
them to...Like Swing does....When you add a data item to a model in
swing it just sort of automatically (via firing awt events in the
background, but still...) paints the region of the grid that needs to
be painted to add this item in...Tapestry could so easily do this as
well. I think it would be so elegant and easy to do that the other
frameworks would have to more or less be quiet and/or do a lot of
backtracking and justification for why their users have to go through
what they do to do the same thing that you get in tapestry for free
without even thinking about it....If only....

I think things could be done that not even the holy RoR or other
similar frameworks could touch currently. A totally new way of
attacking this whole "ajax" thing. ..Maybe some day....some day....

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


Re: Component Specification

Posted by Matt Welch <ma...@welchkin.net>.
On 11/15/05, Howard Lewis Ship <hl...@gmail.com> wrote:
> We'll have to see where Wicket goes, but anyone who has worked on
> Tapestry 4.0, with its extensive support for injection, will certainly
> find that somewhat missing in Wicket's simpler model.

Is there a thread somewhere or some documentation that discusses the
"extensive support for injection"? I understand "injection" in the
general sense, but I'm not sure what it means in the context of
Tapestry (perhaps I just haven't gotten far enough in my tutorials).
I'd be interested if anyone can relate an example scenario they've
encountered where it was useful.

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


Re: Component Specification

Posted by Howard Lewis Ship <hl...@gmail.com>.
Some constructs are easier to express in XML than inside the HTML;
typically, complex OGNL expressions.

When building base pages from which you may extend (or base
components), using annotations is great because it provides an
inheritance mechanism.  Tapestry 3.0 and earlier didn't have any kind
of inheritance mechanism ... often, many different subclasses would
have to include identical snippets of XML.

I widely use a mix of all three, depending on the situation.

It's a bit too late to get this perfect in Tapestry 4.0.  What's there
is good enough, consider it a kind of "trial balloon", that leaves
plenty of room open for later improvements. I, too, would like
something less
clunky than the current annotations and I have some ideas for this for
4.1 ... basically, methods to invoke inside finishLoad() to provide
bindings for parameters there, rather than in annotations (or in
templates or in XML).

However, unlike Wicket (and JSF), I'm very comitted to the basic
premise that Tapestry pages are static in structure, and consistent
between instances (and between servers in a cluster).  Therefore, the
style of "new For()" discussed in this message is not a good fit, it
opens up Tapestry for many impossible to trace errors. Instead,
Tapestry will continue to be highly dynamic when rendering (via
Block/RenderBlock and friends).

We'll have to see where Wicket goes, but anyone who has worked on
Tapestry 4.0, with its extensive support for injection, will certainly
find that somewhat missing in Wicket's simpler model.

On 11/15/05, Matt Welch <ma...@welchkin.net> wrote:
> What are the downsides of defining the components in the template
> itself? The only one I see off the top of my head (and it's not minor,
> I grant) is that if your web developer isn't also an application
> developer, there a greater chance the component definitions will get
> mangled when all that information is in the template. Anything else?
>
> Matt
>
>
>
> On 11/15/05, Ron Piterman <rp...@gmx.net> wrote:
> > yes - thats it.
> > you can define the components using annotations which is quite ugly,
> > then you can define them in your html template,
> > then you can define them in your .page (for page classes) or .jwc (for
> > component classes) xml specifications.
> >
> > Ofcause, if you wish your head to spin real bad you can also mix all
> > three :)
> >
> >
> > ציטוט Matt Welch:
> > > On 11/15/05, Ron Piterman <rp...@gmx.net> wrote:
> > >
> > >>You are right, component annotations are clumsy. But, currently there
> > >>are 3 ways to define a component in a page - you might find .jwc or
> > >>.html way more apealing, and still use annotations for injecting or
> > >>setting defaults - that way you still can use what you like
> > >>(annotations) *and* convenient component defs.
> > >
> > >
> > > Ron, could you go into a little more detail about what you're
> > > describing here? What is the ".jwc" way? Is that the same things as
> > > the xxx.page XML file way? I assume the HTML way is by using implicit
> > > components.
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > 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

Re: Tapestry source for implementing pages

Posted by Howard Lewis Ship <hl...@gmail.com>.
Start here:

http://svn.apache.org/viewcvs.cgi/jakarta/tapestry/trunk/framework/src/java/org/apache/tapestry/services/impl/ComponentConstructorFactoryImpl.java?rev=332071&view=markup


On 11/16/05, John Coleman <jo...@ntlworld.com> wrote:
> Can anyone please point me in the direction of the Tapestry class that uses
> java assist to implement the abstract BasePages?
>
> John
>
>
>
> ---------------------------------------------------------------------
> 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


Tapestry source for implementing pages

Posted by John Coleman <jo...@ntlworld.com>.
Can anyone please point me in the direction of the Tapestry class that uses
java assist to implement the abstract BasePages?

John



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


Re: Component Specification

Posted by Ron Piterman <rp...@gmx.net>.
There is first the problem of i18n: if you used localized templates you 
must repeat the definition of components in every template.
I find the html much much much cleaner without components defintions.
basically we use very descriptive jwcid's in the html, and define the 
components in the .jwc/.page . this makes things clean.
For everything else, we use annotations.
Like howard sayed, the great thing about it is inheritance. For every 
application/domain service we use an injection interface, and make the 
component/page class implement it. no typos :)
Cheers,
Ron


ציטוט Matt Welch:
> What are the downsides of defining the components in the template
> itself? The only one I see off the top of my head (and it's not minor,
> I grant) is that if your web developer isn't also an application
> developer, there a greater chance the component definitions will get
> mangled when all that information is in the template. Anything else?
> 
> Matt
> 
> 
> 
> On 11/15/05, Ron Piterman <rp...@gmx.net> wrote:
> 
>>yes - thats it.
>>you can define the components using annotations which is quite ugly,
>>then you can define them in your html template,
>>then you can define them in your .page (for page classes) or .jwc (for
>>component classes) xml specifications.
>>
>>Ofcause, if you wish your head to spin real bad you can also mix all
>>three :)
>>
>>
>>ציטוט Matt Welch:
>>
>>>On 11/15/05, Ron Piterman <rp...@gmx.net> wrote:
>>>
>>>
>>>>You are right, component annotations are clumsy. But, currently there
>>>>are 3 ways to define a component in a page - you might find .jwc or
>>>>.html way more apealing, and still use annotations for injecting or
>>>>setting defaults - that way you still can use what you like
>>>>(annotations) *and* convenient component defs.
>>>
>>>
>>>Ron, could you go into a little more detail about what you're
>>>describing here? What is the ".jwc" way? Is that the same things as
>>>the xxx.page XML file way? I assume the HTML way is by using implicit
>>>components.
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>>
>>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>
>>


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


Re: Component Specification

Posted by Matt Welch <ma...@welchkin.net>.
What are the downsides of defining the components in the template
itself? The only one I see off the top of my head (and it's not minor,
I grant) is that if your web developer isn't also an application
developer, there a greater chance the component definitions will get
mangled when all that information is in the template. Anything else?

Matt



On 11/15/05, Ron Piterman <rp...@gmx.net> wrote:
> yes - thats it.
> you can define the components using annotations which is quite ugly,
> then you can define them in your html template,
> then you can define them in your .page (for page classes) or .jwc (for
> component classes) xml specifications.
>
> Ofcause, if you wish your head to spin real bad you can also mix all
> three :)
>
>
> ציטוט Matt Welch:
> > On 11/15/05, Ron Piterman <rp...@gmx.net> wrote:
> >
> >>You are right, component annotations are clumsy. But, currently there
> >>are 3 ways to define a component in a page - you might find .jwc or
> >>.html way more apealing, and still use annotations for injecting or
> >>setting defaults - that way you still can use what you like
> >>(annotations) *and* convenient component defs.
> >
> >
> > Ron, could you go into a little more detail about what you're
> > describing here? What is the ".jwc" way? Is that the same things as
> > the xxx.page XML file way? I assume the HTML way is by using implicit
> > components.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>

Re: Component Specification

Posted by Ron Piterman <rp...@gmx.net>.
yes - thats it.
you can define the components using annotations which is quite ugly,
then you can define them in your html template,
then you can define them in your .page (for page classes) or .jwc (for 
component classes) xml specifications.

Ofcause, if you wish your head to spin real bad you can also mix all 
three :)


ציטוט Matt Welch:
> On 11/15/05, Ron Piterman <rp...@gmx.net> wrote:
> 
>>You are right, component annotations are clumsy. But, currently there
>>are 3 ways to define a component in a page - you might find .jwc or
>>.html way more apealing, and still use annotations for injecting or
>>setting defaults - that way you still can use what you like
>>(annotations) *and* convenient component defs.
> 
> 
> Ron, could you go into a little more detail about what you're
> describing here? What is the ".jwc" way? Is that the same things as
> the xxx.page XML file way? I assume the HTML way is by using implicit
> components.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> 
> 


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


Re: Component Specification

Posted by Matt Welch <ma...@welchkin.net>.
On 11/15/05, Ron Piterman <rp...@gmx.net> wrote:
> You are right, component annotations are clumsy. But, currently there
> are 3 ways to define a component in a page - you might find .jwc or
> .html way more apealing, and still use annotations for injecting or
> setting defaults - that way you still can use what you like
> (annotations) *and* convenient component defs.

Ron, could you go into a little more detail about what you're
describing here? What is the ".jwc" way? Is that the same things as
the xxx.page XML file way? I assume the HTML way is by using implicit
components.

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


Re: Component Specification

Posted by Ron Piterman <rp...@gmx.net>.
You are right, component annotations are clumsy. But, currently there 
are 3 ways to define a component in a page - you might find .jwc or 
.html way more apealing, and still use annotations for injecting or 
setting defaults - that way you still can use what you like 
(annotations) *and* convenient component defs.


ציטוט Matt Welch:
> I'm just getting into Tapestry and while I like many of the concepts,
> I'm finding it to be a little complex. Here's an example. It's my
> understanding that specifying components for you pages via annotation
> is new to Tapestry 4.0. I'm a fan of annotations however, in this case
> they seem a little clumsy. Here's an example from my adaptation of the
> tutorial I'm following (Kent Tong's Enjoying Web Development with
> Tapestry):
> 
> 
> @Component(
> 	id="productsLoop",
> 	type="For",
> 	bindings={
> 			"source=products",
> 			"value=currentProduct",
> 			"element=literal:tr"
> 			}
> )
> public abstract IComponent getProductsFor();
> 
> 
> That's how I declared a For component for the eStore tutorial. I guess
> that's really not so bad and my IDE keep the indentation clean so that
> it's not too hard to follow, but to be honest, what I was kind of
> expecting was something a little more code intensive rather than XML
> or annotation intensive. For instance, if the BasePage or AbstractPage
> had a method like addPageComponent() then in some kind of
> intialization method or perhaps the contstructor I might do something
> like:
> 
> 
> {
>     For productsLoop = new For();
>     products.setId("productsLoop");
>     productsLoop.setSource(getProducts());
>     productsLoop.setValue(getCurrentProduct());
>     productsLoop.setElement("tr");
>     addPageComponent(productsLoop);
> }
> 
> 
> I'm guessing that this alternate way of doing things doesn't exist
> since I haven't seen any tutorials or examples that show anything like
> that. Has anyone ever tried to do something like that or would there
> be drastic changes to core framework needed?
> 
> Again, I'm pretty new to Tapestry so it may be that I'll get used to
> such heavy annotations/XML in time, so take this for what it is: a
> newb's first impressions.
> 
> Matt Welch
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> 
> 


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


Re: Component Specification

Posted by Jesse Kuhnert <jk...@gmail.com>.
The code intensive portion looks very unappealing as well. That sort
of intensity only makes sense in actual GUI applications, where you
don't really have any other place to define these
layouts/containers/etc...IMho..

But, Tapestry certainly could be better. Some things aren't always
quite as easy to pick up, despite the frustrations brought about when
this is mentioned.

tick tock tick tock......

On 11/15/05, Matt Welch <ma...@welchkin.net> wrote:
> Actually, Wicket was at the top of our list of potential frameworks
> for this new project, however the app we're building will get some
> fairly high traffic and we were concerned that there we no performance
> or load testing numbers available for Wicket. We would have had to
> implement a significant proof-of-concept app in Wicket and then
> perform testing on it to see if it would meet our needs. That's still
> something we're considering, but this is why we're looking at Tapestry
> first. We're it not for these "unknowns" surrounding Wicket, then we
> would have already started down that road. The other developers on the
> team we very impressed with our initial evaluation of it.
>
> I've been following Tapesty from the outside (via various blogs and an
> occasional peek at this newsgroup) for about a year, but this is my
> first time actually implementing anything in it and it's not quite was
> I was expecting.
>
> Matt Welch
>
>
>
> On 11/14/05, Robert Zeigler <ro...@scazdl.org> wrote:
> > If you're looking for a code-intensive framework, you might try wicket
> > (http://wicket.sourceforge.net) or click (http://click.sourceforge.net).
> > I haven't used either, personally, but have heard good things about
> > both.
> >
> > Robert
> >
> > On Mon, 2005-11-14 at 22:13 -0600, Matt Welch wrote:
> > > I'm just getting into Tapestry and while I like many of the concepts,
> > > I'm finding it to be a little complex. Here's an example. It's my
> > > understanding that specifying components for you pages via annotation
> > > is new to Tapestry 4.0. I'm a fan of annotations however, in this case
> > > they seem a little clumsy. Here's an example from my adaptation of the
> > > tutorial I'm following (Kent Tong's Enjoying Web Development with
> > > Tapestry):
> > >
> > >
> > > @Component(
> > >       id="productsLoop",
> > >       type="For",
> > >       bindings={
> > >                       "source=products",
> > >                       "value=currentProduct",
> > >                       "element=literal:tr"
> > >                       }
> > > )
> > > public abstract IComponent getProductsFor();
> > >
> > >
> > > That's how I declared a For component for the eStore tutorial. I guess
> > > that's really not so bad and my IDE keep the indentation clean so that
> > > it's not too hard to follow, but to be honest, what I was kind of
> > > expecting was something a little more code intensive rather than XML
> > > or annotation intensive. For instance, if the BasePage or AbstractPage
> > > had a method like addPageComponent() then in some kind of
> > > intialization method or perhaps the contstructor I might do something
> > > like:
> > >
> > >
> > > {
> > >     For productsLoop = new For();
> > >     products.setId("productsLoop");
> > >     productsLoop.setSource(getProducts());
> > >     productsLoop.setValue(getCurrentProduct());
> > >     productsLoop.setElement("tr");
> > >     addPageComponent(productsLoop);
> > > }
> > >
> > >
> > > I'm guessing that this alternate way of doing things doesn't exist
> > > since I haven't seen any tutorials or examples that show anything like
> > > that. Has anyone ever tried to do something like that or would there
> > > be drastic changes to core framework needed?
> > >
> > > Again, I'm pretty new to Tapestry so it may be that I'll get used to
> > > such heavy annotations/XML in time, so take this for what it is: a
> > > newb's first impressions.
> > >
> > > Matt Welch
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>

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


Re: Component Specification

Posted by Matt Welch <ma...@welchkin.net>.
Actually, Wicket was at the top of our list of potential frameworks
for this new project, however the app we're building will get some
fairly high traffic and we were concerned that there we no performance
or load testing numbers available for Wicket. We would have had to
implement a significant proof-of-concept app in Wicket and then
perform testing on it to see if it would meet our needs. That's still
something we're considering, but this is why we're looking at Tapestry
first. We're it not for these "unknowns" surrounding Wicket, then we
would have already started down that road. The other developers on the
team we very impressed with our initial evaluation of it.

I've been following Tapesty from the outside (via various blogs and an
occasional peek at this newsgroup) for about a year, but this is my
first time actually implementing anything in it and it's not quite was
I was expecting.

Matt Welch



On 11/14/05, Robert Zeigler <ro...@scazdl.org> wrote:
> If you're looking for a code-intensive framework, you might try wicket
> (http://wicket.sourceforge.net) or click (http://click.sourceforge.net).
> I haven't used either, personally, but have heard good things about
> both.
>
> Robert
>
> On Mon, 2005-11-14 at 22:13 -0600, Matt Welch wrote:
> > I'm just getting into Tapestry and while I like many of the concepts,
> > I'm finding it to be a little complex. Here's an example. It's my
> > understanding that specifying components for you pages via annotation
> > is new to Tapestry 4.0. I'm a fan of annotations however, in this case
> > they seem a little clumsy. Here's an example from my adaptation of the
> > tutorial I'm following (Kent Tong's Enjoying Web Development with
> > Tapestry):
> >
> >
> > @Component(
> >       id="productsLoop",
> >       type="For",
> >       bindings={
> >                       "source=products",
> >                       "value=currentProduct",
> >                       "element=literal:tr"
> >                       }
> > )
> > public abstract IComponent getProductsFor();
> >
> >
> > That's how I declared a For component for the eStore tutorial. I guess
> > that's really not so bad and my IDE keep the indentation clean so that
> > it's not too hard to follow, but to be honest, what I was kind of
> > expecting was something a little more code intensive rather than XML
> > or annotation intensive. For instance, if the BasePage or AbstractPage
> > had a method like addPageComponent() then in some kind of
> > intialization method or perhaps the contstructor I might do something
> > like:
> >
> >
> > {
> >     For productsLoop = new For();
> >     products.setId("productsLoop");
> >     productsLoop.setSource(getProducts());
> >     productsLoop.setValue(getCurrentProduct());
> >     productsLoop.setElement("tr");
> >     addPageComponent(productsLoop);
> > }
> >
> >
> > I'm guessing that this alternate way of doing things doesn't exist
> > since I haven't seen any tutorials or examples that show anything like
> > that. Has anyone ever tried to do something like that or would there
> > be drastic changes to core framework needed?
> >
> > Again, I'm pretty new to Tapestry so it may be that I'll get used to
> > such heavy annotations/XML in time, so take this for what it is: a
> > newb's first impressions.
> >
> > Matt Welch
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>

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


Re: Component Specification

Posted by Robert Zeigler <ro...@scazdl.org>.
If you're looking for a code-intensive framework, you might try wicket
(http://wicket.sourceforge.net) or click (http://click.sourceforge.net).
I haven't used either, personally, but have heard good things about
both.

Robert

On Mon, 2005-11-14 at 22:13 -0600, Matt Welch wrote:
> I'm just getting into Tapestry and while I like many of the concepts,
> I'm finding it to be a little complex. Here's an example. It's my
> understanding that specifying components for you pages via annotation
> is new to Tapestry 4.0. I'm a fan of annotations however, in this case
> they seem a little clumsy. Here's an example from my adaptation of the
> tutorial I'm following (Kent Tong's Enjoying Web Development with
> Tapestry):
> 
> 
> @Component(
> 	id="productsLoop",
> 	type="For",
> 	bindings={
> 			"source=products",
> 			"value=currentProduct",
> 			"element=literal:tr"
> 			}
> )
> public abstract IComponent getProductsFor();
> 
> 
> That's how I declared a For component for the eStore tutorial. I guess
> that's really not so bad and my IDE keep the indentation clean so that
> it's not too hard to follow, but to be honest, what I was kind of
> expecting was something a little more code intensive rather than XML
> or annotation intensive. For instance, if the BasePage or AbstractPage
> had a method like addPageComponent() then in some kind of
> intialization method or perhaps the contstructor I might do something
> like:
> 
> 
> {
>     For productsLoop = new For();
>     products.setId("productsLoop");
>     productsLoop.setSource(getProducts());
>     productsLoop.setValue(getCurrentProduct());
>     productsLoop.setElement("tr");
>     addPageComponent(productsLoop);
> }
> 
> 
> I'm guessing that this alternate way of doing things doesn't exist
> since I haven't seen any tutorials or examples that show anything like
> that. Has anyone ever tried to do something like that or would there
> be drastic changes to core framework needed?
> 
> Again, I'm pretty new to Tapestry so it may be that I'll get used to
> such heavy annotations/XML in time, so take this for what it is: a
> newb's first impressions.
> 
> Matt Welch
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org


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