You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Jamis Buck <jg...@email.byu.edu> on 2004/02/18 23:51:04 UTC
Tapestry as Enterprise Solution
I need help. And in order to phrase my problem well, I need to give
some background. Please hear me out--any assistance will be greatly
appreciated.
I am currently employed at BYU, and am working with a small team to
determine the feasibility of using Tapestry to architect all of the
University's online systems, going forward. (These systems include, but
are not limited to, student registration, admissions, grading, and
scholarships, maintained by over 200 full-time programmers and interns.)
Our current framework is built on C, but is well-architected
none-the-less, and is exactly tailored to fit the needs of our users.
We'd continue using it, except Those With Say have decreed that we must
move to a Java-based architecture.
We have considered JSP, JSF, Velocity, Cocoon, Maverick, and various
others. It's down now to Tapestry vs. JSP/Struts. I (and a few others
on the team) strongly prefer Tapestry's approach to things, and we're
trying to make Tapestry support (more or less) the features our users
enjoyed in our C framework.
All of our applications (and there are probably hundreds of them) will
have the same "look": an identifying banner across the top, an optional
"anchor" area below the banner (which can display the key data for the
information being displayed), and the actual content of the page itself.
Although this can be easily done in Tapestry by creating a custom
component and wrapping the contents of each page with it, the annoyance
we have is this: if every page is going to look the same, why do we have
to put that "border" component in every template? It would be much more
convenient to simply implement the border in some ancestor Page, and
have every application's page inherit from that ancestor. I've managed
to get this working about 60% of the way by processing the page's
template into a proxy component, and then adding that component to the
larger page layout. For read-only pages, this works beautifully.
However, when a form is submitted, Tapestry complains that it cannot
find the form components (I assume because of the additional abstraction
introduced by the proxy component).
Has anyone tried to do something like this before? If we could make
this work it would go a long way to increasing Tapestry's acceptance
among our developers.
I know it is easy to say that adding the component to every template is
not a very burdensome thing, but the fact is that it increases the
maintenance for the pages. It is something that is easy to forget to
add, which wastes developer time, and it is duplicated code, which makes
it hard to reuse the contents of a template without duplicating the
entire template.
Thanks,
Jamis
--
Jamis Buck
jgb3@email.byu.edu
http://www.jamisbuck.org/blog/jamis.cgi
ruby -h | ruby -e 'a=[];readlines.join.scan(/-(.)\[e|Kk(\S*)|le.l(..)e|#!(\S*)/) {|r| a << r.compact.first };puts "\n>#{a.join(%q/ /)}<\n\n"'
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Tapestry as Enterprise Solution
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Feb 18, 2004, at 5:51 PM, Jamis Buck wrote:
> I am currently employed at BYU, and am working with a small team to
> determine the feasibility of using Tapestry to architect all of the
> University's online systems, going forward. (These systems include,
> but are not limited to, student registration, admissions, grading, and
> scholarships, maintained by over 200 full-time programmers and
> interns.)
Dang, *200* full-time programmers?! We are building enterprise-scale
(who isn't?! :) Tapestry applications for graduate business schools and
sell them to the likes of Columbia University, our own school, and the
rest of the who's who of the top business schools in the country. But
we only have a measly half dozen folks. Our systems currently include
an Alumni application (written in Struts last year), and now we are
building Career Services and Admissions/Inquiry/Recommender stuff in
Tapestry (we're not deployed in production with Tapestry yet, but are
making solid progress).
> Although this can be easily done in Tapestry by creating a custom
> component and wrapping the contents of each page with it, the
> annoyance we have is this: if every page is going to look the same,
> why do we have to put that "border" component in every template? It
> would be much more convenient to simply implement the border in some
> ancestor Page, and have every application's page inherit from that
> ancestor. I've managed to get this working about 60% of the way by
> processing the page's template into a proxy component, and then adding
> that component to the larger page layout. For read-only pages, this
> works beautifully. However, when a form is submitted, Tapestry
> complains that it cannot find the form components (I assume because of
> the additional abstraction introduced by the proxy component).
I'm not sure what Tapestry is complaining about. But here are some
thoughts. Perhaps SiteMesh could work, or a servlet filter?
But, my more interesting suggestion is to make all the pages be .html
files *outside* the WAR. Keep the .page files in the WAR though. Be
sure to use the explicit syntax, so that all components are spelled out
in the .page/.jwc files. Set up an ITemplateSourceDelegate (registers
as an extension) which pulls the .html files from the filesystem (or
database even) and wraps the pages with whatever you like.
The advantage is that you can now tweak the templates on a running
system! (certainly caching would be a good thing to do, of course, but
you can control it however you like). All .page files would still need
to specify the Border component, but the .html files would not each
need them.
> Has anyone tried to do something like this before? If we could make
> this work it would go a long way to increasing Tapestry's acceptance
> among our developers.
I have been toying with the ITemplateSourceDelegate. It exposes some
interesting options.
> ruby -h | ruby -e
> 'a=[];readlines.join.scan(/-(.)\[e|Kk(\S*)|le.l(..)e|#!(\S*)/) {|r| a
> << r.compact.first };puts "\n>#{a.join(%q/ /)}<\n\n"'
slick .sig. You create that yourself? I puzzled over it a little
yesterday and finally figured out how it worked :)
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Tapestry as Enterprise Solution
Posted by Jamis Buck <jg...@email.byu.edu>.
Erik Hatcher wrote:
> On Feb 19, 2004, at 2:56 PM, Jamis Buck wrote:
>
>> 3) Set up a custom ITemplateDelegate as an application extension.
>> Define all template files outside of the .war file. Implement the
>> ITemplateDelegate in such a way that it knows where to find the
>> templates, and it can then decorate the templates as needed. PROS:
>> simpler than #2 (only one new object instead of two). CONS: same as
>> #2, must explicitly cache parsed templates, and the template files
>> must be distributed separately from the .war file.
>
>
> Both of your cons I find as pros, in this approach. But, the template
> file location is entirely up to you - and they could live within the
> WAR if you like. Rolling your own caching wouldn't be hard at all.
> One con is that you'd need to specify commonly used components (Border
> for example) in each .page file.
>
> Erik
True, the templates don't have to reside outside the war file. I hadn't
completely thought that all through. However, even though it is not
difficult to roll your own template caching subsystem, it is more LOC,
more code to maintain, and added complexity. It would be best to not
have to do it (ie, take advantage of the existing caching systems in the
DefaultTemplateSource).
- Jamis
--
Jamis Buck
jgb3@email.byu.edu
http://www.jamisbuck.org/blog/jamis.cgi
ruby -h | ruby -e 'a=[];readlines.join.scan(/-(.)\[e|Kk(\S*)|le.l(..)e|#!(\S*)/) {|r| a << r.compact.first };puts "\n>#{a.join(%q/ /)}<\n\n"'
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Tapestry as Enterprise Solution
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Feb 19, 2004, at 2:56 PM, Jamis Buck wrote:
> 3) Set up a custom ITemplateDelegate as an application extension.
> Define all template files outside of the .war file. Implement the
> ITemplateDelegate in such a way that it knows where to find the
> templates, and it can then decorate the templates as needed. PROS:
> simpler than #2 (only one new object instead of two). CONS: same as
> #2, must explicitly cache parsed templates, and the template files
> must be distributed separately from the .war file.
Both of your cons I find as pros, in this approach. But, the template
file location is entirely up to you - and they could live within the
WAR if you like. Rolling your own caching wouldn't be hard at all.
One con is that you'd need to specify commonly used components (Border
for example) in each .page file.
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Tapestry as Enterprise Solution
Posted by Jamis Buck <jg...@email.byu.edu>.
Thank-you to everyone that helped with this. I think I've found a
solution. For future reference (since others may be interested in this
as well) I'll recap all the suggestions, with their pros and cons (as I
percieve them). Feel free to correct me if I err in any statements, or
if I leave anything out.
1) Create a "MyBody" component, which encapsulates the shell, body, and
page layout. It would use a RenderBody component to actually render the
rest of the template at the appropriate place in the output. PROS:
simple, easy to implement, works almost "out of the box". CONS: code
replication (since the component must be placed on every page), higher
maintanence, prone to developer errors (missing closing tag, mistyped
component name, etc.).
2) Implement a custom engine based on BaseEngine that overrides the
createTemplateSource method. This will return a custom implementation
of ITemplateSource, based on DefaultTemplateSource. The template source
object will then be able to decorate any templates it processes, adding
layout information. PROS: not too much code, easy to understand,
potential to nest multiple levels of decoration (ala filters). CONS:
can't take advantage of the existing functionality of the Shell and Body
components without extensive copy-and-paste, requires that each app have
a .application file (to define the Engine class).
3) Set up a custom ITemplateDelegate as an application extension.
Define all template files outside of the .war file. Implement the
ITemplateDelegate in such a way that it knows where to find the
templates, and it can then decorate the templates as needed. PROS:
simpler than #2 (only one new object instead of two). CONS: same as #2,
must explicitly cache parsed templates, and the template files must be
distributed separately from the .war file.
4) Create a TemplatePage that inherits from BasePage. Every page in
your application should then inherit from TemplatePage. Create a new
page called BorderPage that also inherits from BasePage, and which
defines the page layout. It's template will include a property of type
IRender at the location where you want the page content. Override
TemplatePage#renderPage. In the new renderPage method, get the
BorderPage page, add the current page to the BorderPage as the body
component, and then render the BorderPage instance. (I haven't tried
this one explicitly, but my first attempt was similar and it suffered
from a problem when you tried to submit a form--Tapestry couldn't find
the components on the page body.)
5) Create a TemplatePage that inherits from BasePage. Set a template
asset in its constructor that defines the layout template. Create a new
component called PageTemplateProxy and put it in the TemplatePage
template where the page content should go. Inherit all pages from
TemplatePage. Override PageTemplateProxy#finishLoad(cycle,loader,spec)
so that it sets its own template asset to be the path to the inherited
page's template. Then call super.finishLoad(cycle,loader,spec). PROS:
works transparently to the developer. CONS: ognl expressions on the
page template now have the wrong root object, and must be prefixed with
"page." to work correctly.
I've gone with option #5, at least for now. I may try Howard's
suggestion, too (#2, above), but I really like taking advantage of the
Shell and Body components. If I could somehow change the default root
object in the ognl expressions in the PageTemplateProxy object, I would
be a perfectly content man, but it's good enough (putting "page." in
front of the expressions is not a very big deal). If anyone is
interested in seeing my implementation, I'd be happy to post them
(either to the list or to a webpage).
Thanks again for your input!
- Jamis
Mindbridge wrote:
>Hi Jamis,
>
>Here is another approach. I do not have the time to test this at the moment,
>but I think the following should work the way you want it:
>
>- Create a class that inherits BasePage, say TemplatePage. This is the class
>that your pages will override. If they do not have a class and you do not
>want to create a page spec for them (which is logical), set the application
>property 'org.apache.tapestry.default-page-class' to that name of the
>TemplatePage class so it becomes the default instead of BasePage.
>
>- Create a new page that will be your "border", say BorderPage. As a page,
>it will not have parameters, but create a property (say 'bodyComponent') of
>type IRender and at the place where you want the actual page text to go put
>a Delegator component that uses that property. Just make sure that the page
>class inherits BasePage, not TemplatePage.
>
>- in TemplatePage, override the renderPage() method to be the following:
>
>public void renderPage(IMarkupWriter writer, IRequestCycle cycle) {
> try {
> firePageBeginRender();
> beginResponse(writer, cycle);
> if (!cycle.isRewinding())
> cycle.commitPageChanges();
>
> BorderPage page = (BorderPage) cycle.getPage("BorderPage");
> page.setBodyComponent(this);
> // perhaps this should be renderPage rather than render
> page.render(writer, cycle);
> }
> finally {
> firePageEndRender();
> }
>}
>
>This is essentially the original renderPage implementation with a small
>change to do what you need.
>
>That is it -- from here on the pages you create should be "wrapped" in
>BorderPage.
>
>Again, I cannot test this at the moment, but I think it should more or less
>work. Please try it -- it is not much work, I think.
>
>Best regards,
>-mb
>
>----- Original Message -----
>From: "Jamis Buck" <jg...@email.byu.edu>
>To: "Tapestry users" <ta...@jakarta.apache.org>
>Sent: Thursday, February 19, 2004 12:51 AM
>Subject: Tapestry as Enterprise Solution
>
>
>
>
>>I need help. And in order to phrase my problem well, I need to give
>>some background. Please hear me out--any assistance will be greatly
>>appreciated.
>>
>>I am currently employed at BYU, and am working with a small team to
>>determine the feasibility of using Tapestry to architect all of the
>>University's online systems, going forward. (These systems include, but
>>are not limited to, student registration, admissions, grading, and
>>scholarships, maintained by over 200 full-time programmers and interns.)
>>Our current framework is built on C, but is well-architected
>>none-the-less, and is exactly tailored to fit the needs of our users.
>>We'd continue using it, except Those With Say have decreed that we must
>>move to a Java-based architecture.
>>
>>We have considered JSP, JSF, Velocity, Cocoon, Maverick, and various
>>others. It's down now to Tapestry vs. JSP/Struts. I (and a few others
>>on the team) strongly prefer Tapestry's approach to things, and we're
>>trying to make Tapestry support (more or less) the features our users
>>enjoyed in our C framework.
>>
>>All of our applications (and there are probably hundreds of them) will
>>have the same "look": an identifying banner across the top, an optional
>>"anchor" area below the banner (which can display the key data for the
>>information being displayed), and the actual content of the page itself.
>>
>>Although this can be easily done in Tapestry by creating a custom
>>component and wrapping the contents of each page with it, the annoyance
>>we have is this: if every page is going to look the same, why do we have
>>to put that "border" component in every template? It would be much more
>>convenient to simply implement the border in some ancestor Page, and
>>have every application's page inherit from that ancestor. I've managed
>>to get this working about 60% of the way by processing the page's
>>template into a proxy component, and then adding that component to the
>>larger page layout. For read-only pages, this works beautifully.
>>However, when a form is submitted, Tapestry complains that it cannot
>>find the form components (I assume because of the additional abstraction
>>introduced by the proxy component).
>>
>>Has anyone tried to do something like this before? If we could make
>>this work it would go a long way to increasing Tapestry's acceptance
>>among our developers.
>>
>>I know it is easy to say that adding the component to every template is
>>not a very burdensome thing, but the fact is that it increases the
>>maintenance for the pages. It is something that is easy to forget to
>>add, which wastes developer time, and it is duplicated code, which makes
>>it hard to reuse the contents of a template without duplicating the
>>entire template.
>>
>>Thanks,
>>
>>Jamis
>>
>>--
>>Jamis Buck
>>jgb3@email.byu.edu
>>http://www.jamisbuck.org/blog/jamis.cgi
>>
>>ruby -h | ruby -e
>>
>>
>'a=[];readlines.join.scan(/-(.)\[e|Kk(\S*)|le.l(..)e|#!(\S*)/) {|r| a <<
>r.compact.first };puts "\n>#{a.join(%q/ /)}<\n\n"'
>
>
>>---------------------------------------------------------------------
>>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
>
>.
>
>
>
--
Jamis Buck
jgb3@email.byu.edu
http://www.jamisbuck.org/blog/jamis.cgi
ruby -h | ruby -e 'a=[];readlines.join.scan(/-(.)\[e|Kk(\S*)|le.l(..)e|#!(\S*)/) {|r| a << r.compact.first };puts "\n>#{a.join(%q/ /)}<\n\n"'
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Tapestry as Enterprise Solution
Posted by Mindbridge <mi...@yahoo.com>.
Hi Jamis,
Here is another approach. I do not have the time to test this at the moment,
but I think the following should work the way you want it:
- Create a class that inherits BasePage, say TemplatePage. This is the class
that your pages will override. If they do not have a class and you do not
want to create a page spec for them (which is logical), set the application
property 'org.apache.tapestry.default-page-class' to that name of the
TemplatePage class so it becomes the default instead of BasePage.
- Create a new page that will be your "border", say BorderPage. As a page,
it will not have parameters, but create a property (say 'bodyComponent') of
type IRender and at the place where you want the actual page text to go put
a Delegator component that uses that property. Just make sure that the page
class inherits BasePage, not TemplatePage.
- in TemplatePage, override the renderPage() method to be the following:
public void renderPage(IMarkupWriter writer, IRequestCycle cycle) {
try {
firePageBeginRender();
beginResponse(writer, cycle);
if (!cycle.isRewinding())
cycle.commitPageChanges();
BorderPage page = (BorderPage) cycle.getPage("BorderPage");
page.setBodyComponent(this);
// perhaps this should be renderPage rather than render
page.render(writer, cycle);
}
finally {
firePageEndRender();
}
}
This is essentially the original renderPage implementation with a small
change to do what you need.
That is it -- from here on the pages you create should be "wrapped" in
BorderPage.
Again, I cannot test this at the moment, but I think it should more or less
work. Please try it -- it is not much work, I think.
Best regards,
-mb
----- Original Message -----
From: "Jamis Buck" <jg...@email.byu.edu>
To: "Tapestry users" <ta...@jakarta.apache.org>
Sent: Thursday, February 19, 2004 12:51 AM
Subject: Tapestry as Enterprise Solution
> I need help. And in order to phrase my problem well, I need to give
> some background. Please hear me out--any assistance will be greatly
> appreciated.
>
> I am currently employed at BYU, and am working with a small team to
> determine the feasibility of using Tapestry to architect all of the
> University's online systems, going forward. (These systems include, but
> are not limited to, student registration, admissions, grading, and
> scholarships, maintained by over 200 full-time programmers and interns.)
> Our current framework is built on C, but is well-architected
> none-the-less, and is exactly tailored to fit the needs of our users.
> We'd continue using it, except Those With Say have decreed that we must
> move to a Java-based architecture.
>
> We have considered JSP, JSF, Velocity, Cocoon, Maverick, and various
> others. It's down now to Tapestry vs. JSP/Struts. I (and a few others
> on the team) strongly prefer Tapestry's approach to things, and we're
> trying to make Tapestry support (more or less) the features our users
> enjoyed in our C framework.
>
> All of our applications (and there are probably hundreds of them) will
> have the same "look": an identifying banner across the top, an optional
> "anchor" area below the banner (which can display the key data for the
> information being displayed), and the actual content of the page itself.
>
> Although this can be easily done in Tapestry by creating a custom
> component and wrapping the contents of each page with it, the annoyance
> we have is this: if every page is going to look the same, why do we have
> to put that "border" component in every template? It would be much more
> convenient to simply implement the border in some ancestor Page, and
> have every application's page inherit from that ancestor. I've managed
> to get this working about 60% of the way by processing the page's
> template into a proxy component, and then adding that component to the
> larger page layout. For read-only pages, this works beautifully.
> However, when a form is submitted, Tapestry complains that it cannot
> find the form components (I assume because of the additional abstraction
> introduced by the proxy component).
>
> Has anyone tried to do something like this before? If we could make
> this work it would go a long way to increasing Tapestry's acceptance
> among our developers.
>
> I know it is easy to say that adding the component to every template is
> not a very burdensome thing, but the fact is that it increases the
> maintenance for the pages. It is something that is easy to forget to
> add, which wastes developer time, and it is duplicated code, which makes
> it hard to reuse the contents of a template without duplicating the
> entire template.
>
> Thanks,
>
> Jamis
>
> --
> Jamis Buck
> jgb3@email.byu.edu
> http://www.jamisbuck.org/blog/jamis.cgi
>
> ruby -h | ruby -e
'a=[];readlines.join.scan(/-(.)\[e|Kk(\S*)|le.l(..)e|#!(\S*)/) {|r| a <<
r.compact.first };puts "\n>#{a.join(%q/ /)}<\n\n"'
>
>
> ---------------------------------------------------------------------
> 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: Tapestry as Enterprise Solution
Posted by Marilen Corciovei <le...@nemesisit.rdsnet.ro>.
I used an aproach, that is rather simple comparate to the effort you
seem to have put to this: since you are going to use the body component
to each page you can for instance move the body to a mybody component
and just have in each page: a <span jwcid="@MyBody"> instead of a <span
jwcid="@Body"> this way there is no extra component needed. On the other
hand from what I know about tapestry you could just overwrite the Body
component in the .application file. I've used something like that to
overwrite the ValidField component but I am not sure if it applies to
the Body component since it is a more complicated matter.
Hope it helps, Len
On Thu, 2004-02-19 at 00:51, Jamis Buck wrote:
> I need help. And in order to phrase my problem well, I need to give
> some background. Please hear me out--any assistance will be greatly
> appreciated.
>
> I am currently employed at BYU, and am working with a small team to
> determine the feasibility of using Tapestry to architect all of the
> University's online systems, going forward. (These systems include, but
> are not limited to, student registration, admissions, grading, and
> scholarships, maintained by over 200 full-time programmers and interns.)
> Our current framework is built on C, but is well-architected
> none-the-less, and is exactly tailored to fit the needs of our users.
> We'd continue using it, except Those With Say have decreed that we must
> move to a Java-based architecture.
>
> We have considered JSP, JSF, Velocity, Cocoon, Maverick, and various
> others. It's down now to Tapestry vs. JSP/Struts. I (and a few others
> on the team) strongly prefer Tapestry's approach to things, and we're
> trying to make Tapestry support (more or less) the features our users
> enjoyed in our C framework.
>
> All of our applications (and there are probably hundreds of them) will
> have the same "look": an identifying banner across the top, an optional
> "anchor" area below the banner (which can display the key data for the
> information being displayed), and the actual content of the page itself.
>
> Although this can be easily done in Tapestry by creating a custom
> component and wrapping the contents of each page with it, the annoyance
> we have is this: if every page is going to look the same, why do we have
> to put that "border" component in every template? It would be much more
> convenient to simply implement the border in some ancestor Page, and
> have every application's page inherit from that ancestor. I've managed
> to get this working about 60% of the way by processing the page's
> template into a proxy component, and then adding that component to the
> larger page layout. For read-only pages, this works beautifully.
> However, when a form is submitted, Tapestry complains that it cannot
> find the form components (I assume because of the additional abstraction
> introduced by the proxy component).
>
> Has anyone tried to do something like this before? If we could make
> this work it would go a long way to increasing Tapestry's acceptance
> among our developers.
>
> I know it is easy to say that adding the component to every template is
> not a very burdensome thing, but the fact is that it increases the
> maintenance for the pages. It is something that is easy to forget to
> add, which wastes developer time, and it is duplicated code, which makes
> it hard to reuse the contents of a template without duplicating the
> entire template.
>
> Thanks,
>
> Jamis
RE: Tapestry as Enterprise Solution
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
So, basically, you want to have the framework supply a portion of your template and/or page
specification for each page, so that you don't have to.
I can't pull details off the top of my head, but this is a matter of overriding and extending some
of the Tapestry subsystems related to reading page templates and page specifications. With a modest
amount of effort, you can provide your own implementations of some of these subsystems (the
subsystems are accessed via the engine).
For example, by overriding
http://jakarta.apache.org/tapestry/doc/api/org/apache/tapestry/engine/AbstractEngine.html#createTemp
lateSource(org.apache.tapestry.request.RequestContext)
You can provide your own implementation of
http://jakarta.apache.org/tapestry/doc/api/org/apache/tapestry/engine/ITemplateSource.html
That can, for pages in the application namespace, augment the HTML template read from the files in
your web application context with additional content from elsewhere (additional context files, even
a database if you are sufficiently clever).
When I think about these solutions, I generally think in terms of a decorator approach.
Your custom ITemplateSource implementation would build off the framework's
http://jakarta.apache.org/tapestry/doc/api/org/apache/tapestry/engine/DefaultTemplateSource.html
and simply re-invoke most methods on this "inner implementation". In some cases, you would modify
the
http://jakarta.apache.org/tapestry/doc/api/org/apache/tapestry/parse/ComponentTemplate.html
returned by DefaultTemplateSource, adding additional bits appropriate to your situation.
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Tapestry: Java Web Components
http://howardlewisship.com
> -----Original Message-----
> From: jgb3@email.byu.edu [mailto:jgb3@email.byu.edu]
> Sent: Wednesday, February 18, 2004 5:51 PM
> To: Tapestry users
> Subject: Tapestry as Enterprise Solution
>
>
> I need help. And in order to phrase my problem well, I need to give
> some background. Please hear me out--any assistance will be greatly
> appreciated.
>
> I am currently employed at BYU, and am working with a small team to
> determine the feasibility of using Tapestry to architect all of the
> University's online systems, going forward. (These systems
> include, but
> are not limited to, student registration, admissions, grading, and
> scholarships, maintained by over 200 full-time programmers
> and interns.)
> Our current framework is built on C, but is well-architected
> none-the-less, and is exactly tailored to fit the needs of
> our users.
> We'd continue using it, except Those With Say have decreed
> that we must
> move to a Java-based architecture.
>
> We have considered JSP, JSF, Velocity, Cocoon, Maverick, and various
> others. It's down now to Tapestry vs. JSP/Struts. I (and a
> few others
> on the team) strongly prefer Tapestry's approach to things, and we're
> trying to make Tapestry support (more or less) the features our users
> enjoyed in our C framework.
>
> All of our applications (and there are probably hundreds of
> them) will
> have the same "look": an identifying banner across the top,
> an optional
> "anchor" area below the banner (which can display the key
> data for the
> information being displayed), and the actual content of the
> page itself.
>
> Although this can be easily done in Tapestry by creating a custom
> component and wrapping the contents of each page with it, the
> annoyance
> we have is this: if every page is going to look the same, why
> do we have
> to put that "border" component in every template? It would
> be much more
> convenient to simply implement the border in some ancestor Page, and
> have every application's page inherit from that ancestor.
> I've managed
> to get this working about 60% of the way by processing the page's
> template into a proxy component, and then adding that
> component to the
> larger page layout. For read-only pages, this works beautifully.
> However, when a form is submitted, Tapestry complains that it cannot
> find the form components (I assume because of the additional
> abstraction
> introduced by the proxy component).
>
> Has anyone tried to do something like this before? If we could make
> this work it would go a long way to increasing Tapestry's acceptance
> among our developers.
>
> I know it is easy to say that adding the component to every
> template is
> not a very burdensome thing, but the fact is that it increases the
> maintenance for the pages. It is something that is easy to forget to
> add, which wastes developer time, and it is duplicated code,
> which makes
> it hard to reuse the contents of a template without duplicating the
> entire template.
>
> Thanks,
>
> Jamis
>
> --
> Jamis Buck
> jgb3@email.byu.edu
> http://www.jamisbuck.org/blog/jamis.cgi
>
> ruby -h | ruby -e
> 'a=[];readlines.join.scan(/-(.)\[e|Kk(\S*)|le.l(..)e|#!(\S*)/)
> {|r| a << r.compact.first };puts "\n>#{a.join(%q/ /)}<\n\n"'
>
>
> ---------------------------------------------------------------------
> 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