I believe I'm working on what you seek.
I'm working on a project which extends tapestry 5 to pull page/
component templates from an external data store.
Where Tapestry pages are normally pulled from the classpath: or the
context:, I've added another option(http:) which pulls page/component
templates from itself(localhost) on a separate(non-tapestry) servlet
app.
While this has the added work of opening another http connection for
the page/component being accessed, the resulting template is stored
in tapestry's cache and could be invalidated when an update is made to
the database. I'm trying my best to do this without making
changes to tapestry's base code. Now that I've gotten familiar with
the IoC container, I'm comfortable enough to inject and override a
couple
of tapestry's core services. If I'm lucky, creating a tapestry-centric
cms should be as easy as dropping a jar in with tapestry which will
auto-load its tapesty-specific AppModule class.
I know..I'm tooling with services from behind the
org.apache.tapestry.internal curtain while the framework itself is
technically unreleased.
I'm running a risk here, but hopefully the interfaces won't change too
much for the few services I'm overriding.
So far I'm achieving this by overriding the following services with ioc:
http://tapestry.formos.com/nightly/tapestry5/apidocs/org/apache/tapestry/internal/services/PageTemplateLocator.html
http://tapestry.formos.com/nightly/tapestry5/apidocs/org/apache/tapestry/internal/services/ComponentTemplateSource.html
without touching the base code, I'm able to get tapestry to pull the
templates from something other than the context or classpath. It's a
mini-success.
What I really envision though, are page/component templates that are
specific to the hostname being used in the request. I'm able to make
this
work by contributing my own ComponentClassResolver which uses an ugly
hack to tack on the hostname to the primary key used in the cache.
(luckily it's one of the few services where I can extend howard's
implementation and just override a couple methods - many of the other
services are marked "final")
I'm halfway there, http://localhost:8080/start and http://127.0.0.1:8080/start
now pull two separate page templates from the database and work with
tapestry's cache.
What I REALLY want is the ability to change the location component
templates are "searched for" to be in the following places in the
following order:
1 - the database(using http: and a servlet, or perhaps jndi?)
1a - by hostname, page name and component id
1b - by hostname and page name
1c - by hostname
2 - fall back to its classpath resource in ".components." package
eg:
http://localhost:8080/templateservlet/localhost/org.example.app.components.withexternaltemplates.LoginForm:MyLoginPage:myloginform_en.tml
http://localhost:8080/templateservlet/localhost/org.example.app.components.withexternaltemplates.LoginForm:MyLoginPage_en.tml
http://localhost:8080/templateservlet/localhost/org.example.app.components.withexternaltemplates.LoginForm_en.tml
classpath:org
.example.app.components.withexternaltemplates.LoginForm_en.tml
classpath:org.example.app.components.withexternaltemplates.LoginForm.tml
(yeah, all the locale stuff should also stick)
The real-world example: we are to maintain dozens of sites which each
use a login form. The logic behind the login form will not change that
much between sites but the appearance for each site should be different.
The application programmer creates a component class (LoginForm) and a
"functioning" component template which are developed and packaged
together.
Through a web-based page builder, the web designer might create a new
site which needs a login form. Wouldn't it be cool if the designer
could drag and drop from a palette of "web-editable" tapestry
components to the page? When the component is dropped on the page, it
would use the "most matching"(based on hostname, page, id) component
template available but always be able to fall back on the original
login form template(from the classpath) which was written by the
application programmer(and is most likely UGLY).
If the designer wanted to change the appearance of the login form,
they would click an admin-only control which would allow them to edit
a copy of the programmer's TML(from the classpath) which would be
saved to the database. Upon saving, an invalidation event would fire,
and tapestry's template cache would clear, and thus, the next request
for that component would bring its updated template down from the
database and be stored in tapestry's cache.
I'm thinking these "special" components should be treated almost as
portlets for a portal system. Each faux portlet could be
"configurable" from the web with persisting configuration options(in
addition to being able to modify the template).
Could some core developers chime in on whether they think this is
feasible? anyone have any thoughts on this?
If someone wants to collaborate with me, I'd be happy to do so.
-mike
On Dec 7, 2007, at 10:45 AM, Ulrich Stärk wrote:
Performance will vary greatly depending upon which strategy your JCR
implementation uses to persist items. The type and amount of items
you want to store in your repository will also influence
performance. For you, storing thousands of thumbnails in a
repository might not have been the right solution. But I think that
in order to facilitate the maintenance of dynamic Tapestry
applications an interface to a content repository is a good idea.
You don't have to tinker with the templates just because you want
some different text on your pages. Any editor can do it through a
web interface like Magnolia. No need to annoy your application
programmer with this.
Cheers,
Uli
Phillip Rhodes schrieb:
I did write some tapestry components to search, display, upload,
modify contents in a JCR repository, but after we loaded a few
hundred images into the repo, our application slowed to a crawl.
The problem (and it's a common one for many repositories) was that
to return a content item, the repository has to retrieve all
attributes for the node, and this was a separate select statement.
So if your repository has 100 images in it, it would be doing 100+
sql queries to build up the nodes. Once it's loaded, it can be
cached, but this was not a viable option since performance was
critical for me, and we have 1000's of images.
I am just sharing my experience with you so that you consider the
performance of returning 100 thumbnails on your tapestry page in
your design.
In the end, I wrote my tapestry components access a SpringService
that sits on top of a compass/lucene file system repository for
images, content. The SpringService is remotable so that I have
many application servers running against the central repository
server. Next on the roadmap is to implement the backend storage to
be amazon s3. Performance is good because for example, all the
information to display a image is returned in a single lucene
document. meta information for the content is stored in the
filesystem as xml files.
Phillip
----- Original Message -----
From: "Ulrich Stärk" <[EMAIL PROTECTED]>
To: "Tapestry users" <users@tapestry.apache.org>
Sent: Friday, December 7, 2007 9:45:01 AM (GMT-0500) America/New_York
Subject: Re: Web Content Management Systems
You could write some components against the JCR API and access the
underlying repository Magnolia uses (I don't know if this is
possible with OpenCms).
Have a look at the Jackrabbit website (that's the repository
implementation Magnolia uses) to learn how to register the
repository with JNDI. Then just configure Magnolia to use that one
instead of the preconfigured location. Afterwards you are able to
also access the repository from your tapestry webapp with a JNDI
lookup. This approach has some security flaws though. Magnolia has
its own security checks and connects to the repository through just
one user. If you access the repository directly you bypass
Magnolias security layer.
The Jackrabbit website shows how to register the repository with
JNDI in the local web context. So you only have access to the
repository in the context where you registered it. In order to have
your Tapestry app and Magnolia live in different contexts and still
access the same repository you will have to register it globally
thus making it available to ALL contexts in your container. In
combination with the above mentioned this can have serious impacts
on security. So be careful what you do.
Cheers,
Uli
unimatrixzero schrieb:
Hi!
I'm currently testing a few Open Source WCMS Systems like OpenCms
and
Magnolia (Java based).
All this WCMS using JSP's for Templates (together with a own
Taglib) and
Magnolia stores the Content
in an JSR-170 Java Content Repository. I'm wondering if it is
possible to
integrate some Content
from this Content Management System into a Tapestry Application.
Goal would
be that the user
is able to modify content in the Content Management System (like
writing an
article or adding a picture)
and this content could be then included in Tapestry. Is this in
some way
possible?
One of the greatest problems is that Tapestry uses his own kind of
templates
and OpenCms and Magnolia the JSP ones.
Do you think there is a way to integrate this two things?
Maybe you could help me.
Thank you in advance.
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
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]
