You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Morten Sabroe Mortensen <Mo...@yelstream.org> on 2005/04/09 18:35:51 UTC
Application-level control of web-resources
What are the possibilites for application-level control of resources
like JSP-resources?
This would open up for e.g. creating a wiki-like application, where each
wiki-page is a valid JSP-page, which is created dynamically and stored
elsewhere than within the deployed WAR-file.
If anyone fancy this type of functionality - or have tried to implement
it by whatever means possible - please make a statement!
Morten Sabroe Mortensen
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Application-level control of web-resources
Posted by QM <qm...@brandxdev.net>.
On Sun, Apr 10, 2005 at 12:28:26AM +0200, Morten Sabroe Mortensen wrote:
: -Because real pages has more "power" over them than, say, a more simple
: wiki-page parsed to an XML-format and XSLT'et to HTML/XHTML/WML/XHTML-MP
: -whatever.
Depends on your perspective.
Some people would say, they don't want the pages themselves to have
power. Common thought these days is to make the pages -- or any other
component -- as dumb as possible. They should know just enough to do
their job, which in the case of a page is usually, "make the pretty
HTML." =)
: I want to be free to stash the content in a database, the file-system or
: some other WAR-external resource.
I don't see what's stopping you from doing this..? WAR-external content
is nothing new. People are regularly advised to do this if their content
(say, dynamically-served images) and code (webapp) must vary independently.
: I want to be free to have my hieracial
: "wiki-like" system deliver content by different means of processing -
: dynamic JSP's being the "missing link".
What is a "dynamic JSP?"
: Up until now, no filter or front-controller can control the origin or
: WAR-resources.
?
Please explain.
-QM
--
software -- http://www.brandxdev.net/
tech news -- http://www.RoarNetworX.com/
code scan -- http://www.JxRef.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
pregenerating dynamic pages -> Re: Application-level control of web-resources
Posted by Robert Koberg <ro...@koberg.com>.
Here is an example of a poll. Given a poll content piece like:
<?xml version="1.0" encoding="UTF-8"?>
<poll id="pollUID">
<question>
<p>[ Question 1 ]</p>
</question>
<answer id="a1UID">
<p>Agree</p>
</answer>
<answer id="a2UID">
<p>Disagree</p>
</answer>
</poll>
This is used to populate the Poll feature/data in Jive Forums webapp.
The authorized author does not use the Jive admin interface, rather,
they stay in the CMS to create the poll content piece and assign it to a
page. The XSL below is used for providing runtime Velocity code for:
a.) adding the poll to the Jive DB at runtime if it does not exist
b.) display the poll form if the user has not taken it, or
c.) display the results if the user has taken it
(the $xmlpoll is a Velocity request scoped Tool)
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
version="1.0">
<!--
-->
<xsl:template match="answer" mode="addOptionsToDb">
<xsl:text>$xmlpoll.addOption("</xsl:text>
<xsl:value-of select="normalize-space(.)"/>
<xsl:text>")</xsl:text>
</xsl:template>
<!--
-->
<xsl:template match="answer" mode="setOptionsToDb">
<xsl:text>$xmlpoll.setOption(</xsl:text>
<xsl:value-of select="position() - 1"/>
<xsl:text>, "</xsl:text>
<xsl:value-of select="normalize-space(.)"/>
<xsl:text>")</xsl:text>
</xsl:template>
<!--
-->
<xsl:template match="poll">
<xsl:param name="xml_id" select="''"/>
<xsl:variable
name="poll_md"
select="document(concat('metadata/content/', $xml_id,
'.xml'))/s:md-content"/>
<xsl:comment>
#set ($pollName = "<xsl:value-of select="$xml_id"/>")
#set ($poll = $xmlpoll.getPoll($pollName))
#if ($poll)
#if ($xmlpoll.isModified("<xsl:value-of
select="$poll_md/@modified"/>"))
$xmlpoll.setDescription("<xsl:value-of
select="question/simpleText"/>")
<xsl:apply-templates select="answer" mode="setOptionsToDb"/>
#end
#else
#set ($poll = $xmlpoll.createPoll($pollName))
$xmlpoll.setDescription("<xsl:value-of
select="question/simpleText"/>");
<xsl:apply-templates select="answer" mode="addOptionsToDb"/>
#end
</xsl:comment>
<div class="section" xmlns="http://www.w3.org/1999/xhtml">
<h2>Poll</h2>
<xsl:comment>
#if ($isMember)
#if (!$xmlpoll.hasUserVoted($pageUser))
#if ($request.getParameter("doSave"))
#set ($answer = $request.getParameter("q<xsl:value-of
select="$xml_id"/>"))
$xmlpoll.addUserVote($answer, $pageUser)
#else
</xsl:comment>
<form action="{$lsb_focus_nodeset/@name}" method="post"
id="form_{$xml_id}">
<xsl:if test="boolean(@bg_img)">
<xsl:attribute name="style">
<xsl:text>background-image:/images/</xsl:text>
<xsl:value-of select="@bg_img"/>
</xsl:attribute>
</xsl:if>
<xsl:apply-templates select="question" mode="not_saved">
<xsl:with-param name="mc_id" select="$xml_id"/>
</xsl:apply-templates>
<xsl:apply-templates select="answer" mode="not_saved">
<xsl:with-param name="mc_id" select="$xml_id"/>
</xsl:apply-templates>
<input type="submit" value="Vote" name="doSave"/>
<input type="hidden" name="quiz_id" id="quiz_id"
value="{$xml_id}"/>
</form>
<xsl:comment>
#end
#end
#end
</xsl:comment>
<xsl:comment>
#if ($xmlpoll.hasUserVoted($pageUser) || !$isMember)
</xsl:comment>
<xsl:apply-templates select="question" mode="not_saved">
<xsl:with-param name="mc_id" select="$xml_id"/>
</xsl:apply-templates>
<xsl:comment>
#if (!$isMember)
</xsl:comment>
<p><em>Only members can vote in polls.</em></p>
<xsl:comment>
#end
#set ($results = $xmlpoll.getResults())
#foreach ($result in $results)
</xsl:comment>
<div>${result.num}. ${result.question} -
${result.voteCount} votes ${result.percentage}%</div>
<xsl:comment>
#end
#end
</xsl:comment>
</div>
</xsl:template>
<!--
-->
</xsl:stylesheet>
Robert Koberg wrote:
> QM wrote:
> (snip :)
>
>> : to know your thoughts regarding pregenerating JSP or velocity
>> templates : such that the decoration (and content inclusion) happens
>> prior to runtime.
>>
>> I don't think I understand what you're after here, but it's a little
>> early in the morning for me =)
>> Please, explain again.
>>
>>
>> : For example, we use XSLT to pregenerate the pages (managed through
>> our : CMS) so that as much as possible exists in the page/template.
>> This : leaves only what is *required* to be dynamic for runtime.
>> Thoughts? (I : can take it :)
>>
>> I suppose what I don't understand is, what is "dynamic" here? Are you
>> talking a menu that's regenerated at each request (in case new menu
>> items have been added) or something else?
>
>
> (Perhaps I should have changed the subject line)
>
> Are you familiar with apache Forrest? You know how they generate a
> static site, right? Well, think of that, but instead generating XHTML it
> generates Velocity or JSP pages to be used on a live site (after going
> through a QA site first, of course :). In a way, it is a cache. (Our CMS
> does the similar things as Forrest)
>
> In the case of new menu items being added, it is done through the CMS
> (or by hand) and all of the appropriate pages that need to contain that
> item are re-pre-generated.
>
> For example, we have a web app that has quite a few (80-90%) content
> heavy pages where the only thing that needs to be dynamic is the user's
> username displaying and that user's particular choice of CSS files.
> Instead of 'decoratorating' at runtime, it is already decorated, the
> content already exists on the page and the only dynamic things are
> minor. XSLT is used for decoration prior to runtime. At runtime (I guess
> a term left over from my CDROM days), no XSLT is used, rather the
> pregenerated Velocity page/templates (or JSP, but angle brackets tend to
> make for more work with regard to XSLT/XML).
>
> best,
> -Rob
>
>
>
>>
>> -QM
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Application-level control of web-resources
Posted by Robert Koberg <ro...@koberg.com>.
QM wrote:
(snip :)
> : to know your thoughts regarding pregenerating JSP or velocity templates
> : such that the decoration (and content inclusion) happens prior to runtime.
>
> I don't think I understand what you're after here, but it's a little
> early in the morning for me =)
>
> Please, explain again.
>
>
> : For example, we use XSLT to pregenerate the pages (managed through our
> : CMS) so that as much as possible exists in the page/template. This
> : leaves only what is *required* to be dynamic for runtime. Thoughts? (I
> : can take it :)
>
> I suppose what I don't understand is, what is "dynamic" here? Are you
> talking a menu that's regenerated at each request (in case new menu
> items have been added) or something else?
(Perhaps I should have changed the subject line)
Are you familiar with apache Forrest? You know how they generate a
static site, right? Well, think of that, but instead generating XHTML it
generates Velocity or JSP pages to be used on a live site (after going
through a QA site first, of course :). In a way, it is a cache. (Our CMS
does the similar things as Forrest)
In the case of new menu items being added, it is done through the CMS
(or by hand) and all of the appropriate pages that need to contain that
item are re-pre-generated.
For example, we have a web app that has quite a few (80-90%) content
heavy pages where the only thing that needs to be dynamic is the user's
username displaying and that user's particular choice of CSS files.
Instead of 'decoratorating' at runtime, it is already decorated, the
content already exists on the page and the only dynamic things are
minor. XSLT is used for decoration prior to runtime. At runtime (I guess
a term left over from my CDROM days), no XSLT is used, rather the
pregenerated Velocity page/templates (or JSP, but angle brackets tend to
make for more work with regard to XSLT/XML).
best,
-Rob
>
> -QM
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Application-level control of web-resources
Posted by QM <qm...@brandxdev.net>.
On Sat, Apr 09, 2005 at 02:45:46PM -0700, Robert Koberg wrote:
: I know what you say is the prevailing wisdom.
Prevailing wisdom, bah! =) It's just "what's common at the moment."
When a person strays from that norm, they either end up in a world of
hurt or they create something that revolutionizes how things are done..
which means, over time, *that* becomes "what's common at the moment." =)
: to know your thoughts regarding pregenerating JSP or velocity templates
: such that the decoration (and content inclusion) happens prior to runtime.
I don't think I understand what you're after here, but it's a little
early in the morning for me =)
Please, explain again.
: For example, we use XSLT to pregenerate the pages (managed through our
: CMS) so that as much as possible exists in the page/template. This
: leaves only what is *required* to be dynamic for runtime. Thoughts? (I
: can take it :)
I suppose what I don't understand is, what is "dynamic" here? Are you
talking a menu that's regenerated at each request (in case new menu
items have been added) or something else?
-QM
--
software -- http://www.brandxdev.net/
tech news -- http://www.RoarNetworX.com/
code scan -- http://www.JxRef.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Application-level control of web-resources
Posted by Robert Koberg <ro...@koberg.com>.
QM wrote:
> On Sat, Apr 09, 2005 at 06:35:51PM +0200, Morten Sabroe Mortensen wrote:
> : This would open up for e.g. creating a wiki-like application, where each
> : wiki-page is a valid JSP-page, which is created dynamically and stored
> : elsewhere than within the deployed WAR-file.
>
> Why use real pages? Those are a pain to manage, especially in Java
> webapps (which are supposed to be sealed applications).
Hi QM,
I know what you say is the prevailing wisdom. But, I would be interested
to know your thoughts regarding pregenerating JSP or velocity templates
such that the decoration (and content inclusion) happens prior to runtime.
For example, we use XSLT to pregenerate the pages (managed through our
CMS) so that as much as possible exists in the page/template. This
leaves only what is *required* to be dynamic for runtime. Thoughts? (I
can take it :)
best,
-Rob
>
> Many such systems (think blogs) stash the content in a database (or some
> other data store) and map URIs to those entries. In turn, accessing a
> URL merges the content and a static template at runtime. The end-user
> doesn't know they're hitting a virtual resource and, quite frankly, they
> shouldn't care.
>
> Read up on the "Front Controller," "Page Controller," and "Decorator"
> design patterns for insight.
>
> -QM
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
RE: Application-level control of web-resources
Posted by Morten Sabroe Mortensen <Mo...@yelstream.org>.
Hi QM,
-Because real pages has more "power" over them than, say, a more simple
wiki-page parsed to an XML-format and XSLT'et to HTML/XHTML/WML/XHTML-MP
-whatever.
I want to be free to stash the content in a database, the file-system or
some other WAR-external resource. I want to be free to have my hieracial
"wiki-like" system deliver content by different means of processing -
dynamic JSP's being the "missing link".
If the application is in control, it can pre-validate or restrict the
pages to exclude, say, scripting and to enforce, say, a valid XML form
of JSP's, in any way it wants to.
It is a matter of technical freedom.
Up until now, no filter or front-controller can control the origin or
WAR-resources.
Morten Sabroe Morten
-----Original Message-----
From: QM [mailto:qm300@brandxdev.net]
Sent: 9. april 2005 23:32
To: Tomcat Users List
Subject: Re: Application-level control of web-resources
On Sat, Apr 09, 2005 at 06:35:51PM +0200, Morten Sabroe Mortensen wrote:
: This would open up for e.g. creating a wiki-like application, where
each
: wiki-page is a valid JSP-page, which is created dynamically and stored
: elsewhere than within the deployed WAR-file.
Why use real pages? Those are a pain to manage, especially in Java
webapps (which are supposed to be sealed applications).
Many such systems (think blogs) stash the content in a database (or some
other data store) and map URIs to those entries. In turn, accessing a
URL merges the content and a static template at runtime. The end-user
doesn't know they're hitting a virtual resource and, quite frankly, they
shouldn't care.
Read up on the "Front Controller," "Page Controller," and "Decorator"
design patterns for insight.
-QM
--
software -- http://www.brandxdev.net/
tech news -- http://www.RoarNetworX.com/
code scan -- http://www.JxRef.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Application-level control of web-resources
Posted by QM <qm...@brandxdev.net>.
On Sat, Apr 09, 2005 at 06:35:51PM +0200, Morten Sabroe Mortensen wrote:
: This would open up for e.g. creating a wiki-like application, where each
: wiki-page is a valid JSP-page, which is created dynamically and stored
: elsewhere than within the deployed WAR-file.
Why use real pages? Those are a pain to manage, especially in Java
webapps (which are supposed to be sealed applications).
Many such systems (think blogs) stash the content in a database (or some
other data store) and map URIs to those entries. In turn, accessing a
URL merges the content and a static template at runtime. The end-user
doesn't know they're hitting a virtual resource and, quite frankly, they
shouldn't care.
Read up on the "Front Controller," "Page Controller," and "Decorator"
design patterns for insight.
-QM
--
software -- http://www.brandxdev.net/
tech news -- http://www.RoarNetworX.com/
code scan -- http://www.JxRef.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
RE: Application-level control of web-resources
Posted by Morten Sabroe Mortensen <Mo...@yelstream.org>.
...To be more specific, I consider creating my own custom-modification
of Tomcat including functionality for application-level control of
resources - see the below sketch. I kind of think upon a modified
'JspServlet' hidden behind a nice interface so as to avoid fiddling
directly with JSP-compilation and so on.
Is this possible?
How hard is it to implement?
Are there alternatives (like hacking class-loaders or
file-system-access)?
I believe, that it can be done by direct JSPC-invocation or abuse of the
file-system containing unpacked WAR's - both compromises the integrity
of WAR's - I do not consider any of these a clean of "pure" way of doing
it. I want programmatic control.
Dynamic JSP's/resources are (sadly) not part of Sun's specifications.
As far as I can tell from a short look at the source-code for Tomcat, it
should not be too hard to create this functionality. It would be a nice
experiment.
If you care to comment, I would like to here some opinions from people
with insight into the internals of Tomcat.
Morten Sabroe Mortensen
----- BEGIN: Idea for application-level control of resources: -----
The idea is this:
A web-resource like e.g. a JSP-page is to be obtained by the
servlet-engine from the web-application through an interface like this:
/**
* Description of a resource within the context of a servlet-engine. */
public interface Resource {
/**
*
*/
long getTimeModification()
throws
IOException;
/**
*
*/
InputStream getInputStream(String path)
throws
IOException;
}
When a user-agent addresses e.g. a JSP-page, a 'ResourceManager' set by
the application is requested by the servlet-engine with the purpose of
delivering the resource:
ServletContext (modified - Tomcat-specific):
void setResourceManager(ResourceManager resourceManager) ...
ResourceManager getResourceManager() ...
Resource getResourceAsResource(String path)
{
Resource res=null;
{
ResourceManager resourceManager=getResourceManager();
if (resourceManager!=null)
{
res=resourceManager.getResource(path);
}
}
return res;
}
void addResourceListener(ResourceListener l)
void removeResourceListener(ResourceListener l)
void fireResourceUpdate(ResourceEvent ev)
interface ResourceManager:
Resource getResource(String path) ...
interface ResourceListener:
void onResourceUpdate(ResourceEvent ev) ... //event-object must
contain path-information
There could be two strategies for accessing a resource:
1) Each time a resource like e.g. a JSP-page is requested, the
servlet-engine performs a lookup for the 'Resource' object and uses
'getTimeModification()' to determine, if the JSP-page has changed and
therefore should be re-compiled and re-loaded. The resource could also
have been removed completely, which would result in no 'Resource' object
being found and 'null' returned - in which case the page no longer
exists.
2) The application always notifies the servlet-engine about changes to
resources. If a resource like e.g. a JSP-page is changed or removed, the
application calls 'fireResourceUpdate()' which again trickers all
'ResourceListener' instances, where the servlet-engine itself per
default has a specific listener added and this listener makes the
servlet-engine perform a lookup for the 'Resource' as in 1).
The 'ResourceManager' could implement a chain-of-responsibility, but
this can be left to the specific application and does not need to be
part of the interface between the servlet-engine and the
web-application.
Interesting types of resources include JSP-pages/-fragments and
tag-libraries.
As I see it, the 'Resource'-type of interface could also be in play,
when Tomcat differs between obtaining resources from an unpacked
WAR-file to when the WAR-file is actually unpacked within the
file-system and JSP-pages are added or changed directly within the
file-system. Tomcat must have something like my 'Resource'-functionality
already, but possibly not expressed as an interface between Tomcat and
web-applications. When moving to a "live" repository like a file-system,
the 'Resource.getTimeModification()' comes into play. There is a
possibility for a unification here.
----- END: Idea for application-level control of resources. -----
-----Original Message-----
From: Morten Sabroe Mortensen [mailto:Morten.Mortensen@yelstream.org]
Sent: 9. april 2005 18:36
To: tomcat-user@jakarta.apache.org
Subject: Application-level control of web-resources
What are the possibilites for application-level control of resources
like JSP-resources?
This would open up for e.g. creating a wiki-like application, where each
wiki-page is a valid JSP-page, which is created dynamically and stored
elsewhere than within the deployed WAR-file.
If anyone fancy this type of functionality - or have tried to implement
it by whatever means possible - please make a statement!
Morten Sabroe Mortensen
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org