Hi Mike,

Did you get anywhere with this. If you need some collaboration, I am about
to try and solve the same problem.

Sean




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.

--
Sent from the Tapestry - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@(protected)
For additional commands, e-mail: users-help@(protected)