Re: Bending Jasper to My Will
Andy Clark wrote: I want Jasper to look for JSP and Tag files in a specific location (e.g. based on a request param); and then fall back to a default location if the file is not found. This would be extremely useful for skinning a webapp. We do something a little like this in a database application to allow sites to create custom pages on a per-database or per-view level. There's a directory of default JSP files which can be overridden by creating subdirectories. When the controller servlet is supposed to forward to a given JSP, it checks the request for the database and view names and first looks for a JSP in jsp//, then in jsp/, then defaults to the one in jsp if no custom version was found. To allow sites to customize JSPs that are included by the standard JSPs, we wrote a custom include tag that does the same lookup. I'm not sure what you'd do about tag files. Aren't they resolved at page compilation time, so you can't change where the tag points to at request time? Maybe your application's tag files could include their bodies somehow. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Bending Jasper to My Will
Alan Chaney wrote: Correct me if I am wrong but you want to have a > level of configuration which is more than just > appearance. It's mostly for appearance but that also ties in with functionality. For example, if a page displays the preferences that a user can change, a skin author can change which preferences are "available" by rewriting the prefs page to not include those elements. But these changes are specific to a class of users that are assigned (or have chosen) that skin. The next thing which isn't clear to me is at who > will choose the feature set. Is this going to be > a runtime thing or a startup configuration thing? > Will your end-users be able to configure things > or will it be the result of specific programming > work? These changes will be made by customers themselves or professional services. We provide a tag library that exposes all of the functionality of our web application. We use this tag library to build the default skin of the app but customers often want to tweak the appearance in ways that go beyond simple CSS changes. In addition, right now there is no way for them to localize their changes to a particular skin. If they make changes to a presentation tag (or JSP) then all other skins see those changes. And one of my primary goals is to allow users to create custom skins without any configuration changes to the web container. Just drop in the skin and it works. I'm currently exploring ways to work around the problem within the confines of what JSPs allow. But I'm having limited success with that route... -AndyC - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bending Jasper to My Will
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andy, Andy Clark wrote: | I want Jasper to look for JSP and Tag files in a | specific location (e.g. based on a request param); | and then fall back to a default location if the | file is not found. This would be extremely useful | for skinning a webapp. I realize this doesn't answer your question (sorry!), but this is exactly what Tiles was written do to. I think there is a JSP Tiles implementation, but, of course, you'd still have to re-hack all your existing files to make it happen. Unfortunately, I don't think you're going to find a silver-bullet solution that you can code-up in in a weekend. Fully-customizable private-labeling solutions usually have to be done from the ground-up, unless you are willing to settle for simple CSS replacements. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEUEARECAAYFAkgOMLEACgkQ9CaO5/Lv0PCl5ACY79bSXXb2UPBmxjza5hKi+zwi 7ACgiJFnC2VUj1jNhNgx5kcVaAEiXpg= =bad+ -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bending Jasper to My Will
Andy I've followed this thread with a some interest because it ties up with some things I've done in the past. I think you are trying to use a technology in an inappropriate way to solve the wrong problem. Correct me if I am wrong but you want to have a level of configuration which is more than just appearance. You want to: 1. be able to add/remove features from a particular page 2. be able to reorder features Is that correct? The next thing which isn't clear to me is at who will choose the feature set. Is this going to be a runtime thing or a startup configuration thing? Will your end-users be able to configure things or will it be the result of specific programming work? Alan Chaney Andy Clark wrote: Lucas wrote: To answer the original question, there is a > mechanism that Tomcat provides to handle the > specific thing you want to achieve. The solution > is very Tomcat specific, so I do not really > recommend it, anyhow, if you really _need_to_have > _this_ then the way to achieve it is the following: [...] Thanks for the suggestion but I think I am out of luck because we're using a different web container. Even though there's a ton of different web containers, they all seem to use Jasper so that's where I was attempting to tackle the problem. But, referring to your specific suggestion, I wonder if there would be a problem. When I was browsing the Jasper source, I noticed that it caches the resolved JSP/tag files. Which means that if I only change the resolution mechanism, it won't work. Because unless I am also able to modify the cache ID, then whichever source file is resolved first for a specific JSP/tag, then that one will be cached and be returned the next time it's referenced, even if the user's skin is different. (If that makes any sense.) PS: This will make yous web app not 100% standard, > and if you have to migrate this behavior to other > web containers, it might get trickier, so be sure > that you really need this. Understood. Which is also why I'm hoping that the Jasper developers would be open to patches that allow it to be extended in this way. Ahh, just one more thing, do not even try to > modify Jasper itself unless you know what you > are doing; Most people experimenting with Jasper end up in nothing. That way leads madness. Got it. :) -AndyC - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] !DSPAM:480e21ea50971721312192! - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bending Jasper to My Will
Lucas wrote: To answer the original question, there is a > mechanism that Tomcat provides to handle the > specific thing you want to achieve. The solution > is very Tomcat specific, so I do not really > recommend it, anyhow, if you really _need_to_have > _this_ then the way to achieve it is the following: [...] Thanks for the suggestion but I think I am out of luck because we're using a different web container. Even though there's a ton of different web containers, they all seem to use Jasper so that's where I was attempting to tackle the problem. But, referring to your specific suggestion, I wonder if there would be a problem. When I was browsing the Jasper source, I noticed that it caches the resolved JSP/tag files. Which means that if I only change the resolution mechanism, it won't work. Because unless I am also able to modify the cache ID, then whichever source file is resolved first for a specific JSP/tag, then that one will be cached and be returned the next time it's referenced, even if the user's skin is different. (If that makes any sense.) PS: This will make yous web app not 100% standard, > and if you have to migrate this behavior to other > web containers, it might get trickier, so be sure > that you really need this. Understood. Which is also why I'm hoping that the Jasper developers would be open to patches that allow it to be extended in this way. Ahh, just one more thing, do not even try to > modify Jasper itself unless you know what you > are doing; Most people experimenting with Jasper end up in nothing. That way leads madness. Got it. :) -AndyC - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bending Jasper to My Will
Hassan wrote: I think that this is a non-starter because the app is already written (quite nicely, I might add) in straight JSPs. If it's already "quite nicely" written, why doesn't > it do what you want? :-) Excellent point! But ultimately there are limitations in the extensibility of the engine that limit what we can do. We're often pushing the boundaries of what the technology can handle. Oh well... nothing is perfect. -AndyC - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bending Jasper to My Will
Ahh, just one more thing, do not even try to modify Jasper itself unless you know what you are doing; Most people experimenting with Jasper end up in nothing. - lg On Tue, Apr 22, 2008 at 1:40 AM, Lucas Galfaso <[EMAIL PROTECTED]> wrote: > Hi All, > To answer the original question, there is a mechanism that Tomcat > provides to handle the specific thing you want to achieve. The > solution is very Tomcat specific, so I do not really recommend it, > anyhow, if you really _need_to_have_this_ then the way to achieve it > is the following: > > - Extend the class FileDirContext to take a second parameter, this > second parameter is the path that will override the standard path. > Code everything into that class so that it works as you expect. > Compile and add the .jar to Tomcat library. > - Add your own context.xml to the application you want to have this > special behavior, just copy the standard one from the conf directory > from Tomcat. In this context.xml add a new resource that points to > your new class with the new path. > - Done. > > This is simpler to explain it that to do it, but it is something that > should be easy to build and test within a day if you know what you > have to change and what you want to achieve. > > Regards, > Lucas Galfaso > > PS: This will make yous web app not 100% standard, and if you have to > migrate this behavior to other web containers, it might get trickier, > so be sure that you really need this. > > > > > > On Tue, Apr 22, 2008 at 12:04 AM, Hassan Schroeder > <[EMAIL PROTECTED]> wrote: > > On Mon, Apr 21, 2008 at 7:16 PM, Andy Clark <[EMAIL PROTECTED]> wrote: > > > > > Many people suggested that I try various frameworks > > > for the application because they contain template > > > engines that may work for my purpose. Unfortunately, > > > I think that this is a non-starter because the app > > > is already written (quite nicely, I might add) in > > > straight JSPs. > > > > If it's already "quite nicely" written, why doesn't it do what you want? > :-) > > > > Just askin' ... > > > > -- > > Hassan Schroeder [EMAIL PROTECTED] > > > > > > > > - > > To start a new topic, e-mail: users@tomcat.apache.org > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bending Jasper to My Will
Hi All, To answer the original question, there is a mechanism that Tomcat provides to handle the specific thing you want to achieve. The solution is very Tomcat specific, so I do not really recommend it, anyhow, if you really _need_to_have_this_ then the way to achieve it is the following: - Extend the class FileDirContext to take a second parameter, this second parameter is the path that will override the standard path. Code everything into that class so that it works as you expect. Compile and add the .jar to Tomcat library. - Add your own context.xml to the application you want to have this special behavior, just copy the standard one from the conf directory from Tomcat. In this context.xml add a new resource that points to your new class with the new path. - Done. This is simpler to explain it that to do it, but it is something that should be easy to build and test within a day if you know what you have to change and what you want to achieve. Regards, Lucas Galfaso PS: This will make yous web app not 100% standard, and if you have to migrate this behavior to other web containers, it might get trickier, so be sure that you really need this. On Tue, Apr 22, 2008 at 12:04 AM, Hassan Schroeder <[EMAIL PROTECTED]> wrote: > On Mon, Apr 21, 2008 at 7:16 PM, Andy Clark <[EMAIL PROTECTED]> wrote: > > > Many people suggested that I try various frameworks > > for the application because they contain template > > engines that may work for my purpose. Unfortunately, > > I think that this is a non-starter because the app > > is already written (quite nicely, I might add) in > > straight JSPs. > > If it's already "quite nicely" written, why doesn't it do what you want? :-) > > Just askin' ... > > -- > Hassan Schroeder [EMAIL PROTECTED] > > > > - > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bending Jasper to My Will
On Mon, Apr 21, 2008 at 7:16 PM, Andy Clark <[EMAIL PROTECTED]> wrote: > Many people suggested that I try various frameworks > for the application because they contain template > engines that may work for my purpose. Unfortunately, > I think that this is a non-starter because the app > is already written (quite nicely, I might add) in > straight JSPs. If it's already "quite nicely" written, why doesn't it do what you want? :-) Just askin' ... -- Hassan Schroeder [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bending Jasper to My Will
On Mon, 2008-04-21 at 19:16 -0700, Andy Clark wrote: > Notice that the JSP/tag files that compose the > response are a mixture of the default ones and the > custom ones that the skin overrides. Skin authors > should not have to make complete copies of the > default skin tree in order to edit only a handful > of files; the system should make that transparent > to them. How about using XSL to pregenerate the JSPs? (I do this but output to the JSP XML syntax.) Your users build up a skin config in your gui(?) which can be used as the main source in the transformation. With this approach you could pretty much do away with the tag files and stick them in through the transformation. You could still use the tag files and bring them in with the document function when indicated as necessary by the config or a wrapping tag. (oh, and since the tag files are not well-formed XML there might be a handy tool out there that can well-form them for you :) ). best, -Rob - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bending Jasper to My Will
Thanks for everyone with their quick responses to
my query regarding how to override tags/JSP files.
My initial posts on the subject can be found here:
http://mail-archives.apache.org/mod_mbox/tomcat-users/200804.mbox/[EMAIL
PROTECTED]
http://mail-archives.apache.org/mod_mbox/tomcat-users/200804.mbox/[EMAIL
PROTECTED]
Many people suggested that I try various frameworks
for the application because they contain template
engines that may work for my purpose. Unfortunately,
I think that this is a non-starter because the app
is already written (quite nicely, I might add) in
straight JSPs.
I took a quick look through the various projects'
websites and documentation. It seems like they all
do roughly the same thing and that many of them
are like JSPs but with their own custom syntax.
That aside, I didn't see anything about how to skin
the app at the level that I want. I saw mechanisms
to use different templates for entire responses but
nothing about overriding individual parts of those
templates. Granted, I could be completely wrong
about any and all of these points because I don't
have first-hand experience with these frameworks.
Anyway, I'd like to clarify my needs a little
further because it didn't seem that the example in
my second post was clear. First, my requirement
are that it use straight JSPs. Second, I must be
able to override any tag or JSP included from another
tag/JSP file, not just whole response pages. Let me
use a more complex example.
Say I have the following response page and source
files: [created just for discussion and edited for
brevity]
<%-- file: response.jsp --%>
<%-- file: /WEB-INF/tags/table.tag --%>
<%-- file: /WEB-INF/tags/header.tag --%>
<%@ attribute name='cols' type='java.util.List' %>
<%-- file: /WEB-INF/tags/headerCell.tag --%>
<%@ attribute name='data' type='java.lang.Object' %>
${data}
<%-- file: /WEB-INF/tags/body.tag --%>
<%@ attribute name='rows' type='java.util.List' %>
<%-- file: /WEB-INF/tags/rowCell.tag --%>
<%@ attribute name='data' type='java.lang.Object' %>
${data}
Looking at the result, the contents of the page are
the result of the composition of all of these JSPs
and tags, structured like so:
response.jsp
/WEB-INF/tags/table.tag
/WEB-INF/tags/header.tag
/WEB-INF/tags/headerCell.tag
...
/WEB-INF/tags/body.tag
/WEB-INF/tags/rowCell.tag
...
What I need is the ability to override any one of
these parts independently and based on a user pref.
Given User 1, 2, and 3 who have skin preference of
, "Foo", and "Bar", respectively, the
output they each see for response.jsp can be
different.
The base case, User 1, that does not have a skin
specified would see the response as structured like
I illustrated above. However, skin "Foo" may replace
the response.jsp file but leave the rest in place.
And skin "Bar" may just replace headerCell.tag and
rowCell.tag. For skin "Foo", the response page
should be different but should continue to use all
of the default tags. Whereas for skin "Bar", the
response page table, header, and body tags stay the
same; but the custom header cell and row cell tags
are used instead of their defaults.
In the last case, the structure of the response
should look like this:
response.jsp
/WEB-INF/tags/table.tag
/WEB-INF/tags/header.tag
/skins/Foo/tags/headerCell.tag
...
/WEB-INF/tags/body.tag
/skins/Foo/tags/rowCell.tag
...
Notice that the JSP/tag files that compose the
response are a mixture of the default ones and the
custom ones that the skin overrides. Skin authors
should not have to make complete copies of the
default skin tree in order to edit only a handful
of files; the system should make that transparent
to them.
Does this make it any clearer? My apologies if the
frameworks mention do exactly this and I just didn't
notice from their documentation. But since the app
is already written, it would make a massive change
to introduce an additional dependency.
As I mentioned in my first post, I browsed through
the Jasper source but didn't see any way to hook
into the JSP/tag file resolution mechanism. I
figured that I could extend a factory class or
register some kind of resolver that would allow me
to achieve the results I need. Unfortunately many
things were final and didn't provide hooks for
extension.
I'm going to be looking for reasonable workarounds
if there's no way to extend Jasper. But if anyone
know of anything else given my requirements, it
would be greatly appreciated.
Thanks!
-AndyC
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bending Jasper to My Will
Easiest way to skin on Apache is dojotoolkit WidgetSkin components
http://dojo.jot.com/WikiHome/WidgetSkinning
The 'beauty' of using Dojo Skin widgets is you can wrap dojo controls within
Struts 2.x taglibs (which are callable from jsp)
http://struts.apache.org/2.0.11.1/index.html
A more difficult to implement but vastly performance driven option is to use
DWR
BTW: The sole developer and technoevangelist for DWR is Joe Walker
http://getahead.org/dwr/
Finally Scriptaculous integration under Appfuse
BTW: The sole developer and technoevangelist for Appfuse is Matt Raible
http://raibledesigns.com/rd/entry/script_aculo_us_vs_dojo
HTH
Martin
- Original Message -
From: "Andy Clark" <[EMAIL PROTECTED]>
To:
Sent: Monday, April 21, 2008 2:43 PM
Subject: Re: Bending Jasper to My Will
> Pid wrote:
> > Andy Clark wrote:
> >> I want Jasper to look for JSP and Tag files in a
> >> specific location (e.g. based on a request param);
> >> and then fall back to a default location if the
> >> file is not found. This would be extremely useful
> >> for skinning a webapp.
> >
> > Cascading Style Sheets are an even more useful,
> > practical and easier to implement solution for
> > skinning a webapp.
> >
> > Failing that, programmatically customising the HTML
> > output of a common set of tag files would be easier.
>
> CSS and DHTML only applies to the client-side and
> does not allow server-side customizations. We need
> to go beyond simple color changes or even changing
> the HTML layout; we need to be able to override any
> or all tags and JSP files in parallel. In other
> words, multiple versions of the code is deployed and
> we want to control which application code to use
> based on the user's settings.
>
> Our application allows users to host multiple domains
> and different user levels, each of which can have a
> different skin. And we currently allow simple changes
> to color, etc via CSS. But if the skin author wants to
> change the functionality or layout, they must modify
> the base JSP files/tags. Which means that *all* of
> the skins see the changes. Not what we want.
>
> For our customers, it is important to be able to
> brand each skin independently and even control which
> features are exposed via the interface. And we have
> no way of knowing all the different ways in which the
> customer wants to modify the application. And... they
> should be able to do all of this without modifying
> the web.xml file.
>
> So what I would like to be able to do (transparently
> from the user) is to, on a request-by-request basis,
> determine which tags/JSP files to use based on that
> user's skin preference. For example, if the user's
> skin is set to "Foo", then I want to look for tag and
> JSP file overrides in the skins/Foo/ directory and
> use those; if I don't find them there, I want to
> fallback and use the tags/JSP files in the default
> directory.
>
> I'll use a more precise example. Say that I have the
> following files in my webapp:
>
>WEB-INF/tags/view.tag
>WEB-INF/tags/button.tag
>skins/Foo/tags/view.tag
>skins/Bar/tags/button.tag
>
> with these contents:
>
><%-- file: WEB-INF/tags/view.tag --%>
>Hello World
>
>
><%-- file: WEB-INF/tags/button.tag --%>
><%@ attribute name='text' required='true' %>
>${text}
>
><%-- file: skins/Foo/tags/view.tag --%>
>Welcome to Clicky McClicker's Clicktastic Emporium
>
>
><%-- file: skins/Bar/tags/button.tag --%>
><%@ attribute name='text' required='true' %>
>${text}
>
> If there are three users whose skin preference is
> set to , Foo, and Bar, respectively, then
> the interface they see is completely different when
> the JSP they hit uses in the page.
>
> User 1 sees:
>
>Hello World
>Click Me
>
> User 2 sees:
>
>Welcome to Clicky McClicker's Clicktastic Emporium
>Clickity Click
>
> User 3 sees:
>
>Hello World
>Click Me
>
> In essence, I need to control Jasper internally to
> do two things:
>
> 1) resolve all requests for tag/JSP files at the
> requested location to look for the same file in
> the user's skin directory; and
>
> 2) failing to find the file in the first location,
> try again at the default location.
>
> I hope this sheds some more light on what I need to
> do. And I really hope there are some Jasper experts
> on the list that can point me in the right direction
> (even if it means patching the Jasper source).
>
>
Re: Bending Jasper to My Will
On Mon, Apr 21, 2008 at 2:43 PM, Andy Clark <[EMAIL PROTECTED]> wrote:
> Pid wrote:
>
>
> > Andy Clark wrote:
> >
> > > I want Jasper to look for JSP and Tag files in a
> > >
> >
> >> specific location (e.g. based on a request param);
> >> and then fall back to a default location if the
> >> file is not found. This would be extremely useful
>
> >
> > > for skinning a webapp.
> > >
> >
> > Cascading Style Sheets are an even more useful,
> >
> > practical and easier to implement solution for
> > skinning a webapp.
> >
> > Failing that, programmatically customising the HTML
> > output of a common set of tag files would be easier.
>
> CSS and DHTML only applies to the client-side and
> does not allow server-side customizations. We need
> to go beyond simple color changes or even changing
> the HTML layout; we need to be able to override any
> or all tags and JSP files in parallel. In other
> words, multiple versions of the code is deployed and
> we want to control which application code to use
> based on the user's settings.
>
> Our application allows users to host multiple domains
> and different user levels, each of which can have a
> different skin. And we currently allow simple changes
> to color, etc via CSS. But if the skin author wants to
> change the functionality or layout, they must modify
> the base JSP files/tags. Which means that *all* of
> the skins see the changes. Not what we want.
>
> For our customers, it is important to be able to
> brand each skin independently and even control which
> features are exposed via the interface. And we have
> no way of knowing all the different ways in which the
> customer wants to modify the application. And... they
> should be able to do all of this without modifying
> the web.xml file.
>
> So what I would like to be able to do (transparently
> from the user) is to, on a request-by-request basis,
> determine which tags/JSP files to use based on that
> user's skin preference. For example, if the user's
> skin is set to "Foo", then I want to look for tag and
> JSP file overrides in the skins/Foo/ directory and
> use those; if I don't find them there, I want to
> fallback and use the tags/JSP files in the default
> directory.
>
> I'll use a more precise example. Say that I have the
> following files in my webapp:
>
> WEB-INF/tags/view.tag
> WEB-INF/tags/button.tag
> skins/Foo/tags/view.tag
> skins/Bar/tags/button.tag
>
> with these contents:
>
> <%-- file: WEB-INF/tags/view.tag --%>
> Hello World
>
>
> <%-- file: WEB-INF/tags/button.tag --%>
> <%@ attribute name='text' required='true' %>
> ${text}
>
> <%-- file: skins/Foo/tags/view.tag --%>
> Welcome to Clicky McClicker's Clicktastic Emporium
>
>
> <%-- file: skins/Bar/tags/button.tag --%>
> <%@ attribute name='text' required='true' %>
> ${text}
>
> If there are three users whose skin preference is
> set to , Foo, and Bar, respectively, then
> the interface they see is completely different when
> the JSP they hit uses in the page.
>
> User 1 sees:
>
> Hello World
> Click Me
>
> User 2 sees:
>
> Welcome to Clicky McClicker's Clicktastic Emporium
> Clickity Click
>
> User 3 sees:
>
> Hello World
> Click Me
>
> In essence, I need to control Jasper internally to
> do two things:
>
> 1) resolve all requests for tag/JSP files at the
>requested location to look for the same file in
>the user's skin directory; and
>
> 2) failing to find the file in the first location,
>try again at the default location.
>
> I hope this sheds some more light on what I need to
> do. And I really hope there are some Jasper experts
> on the list that can point me in the right direction
> (even if it means patching the Jasper source).
>
>
>
> > Customising a web app by implementing different sets
> >
> > of tag files seems like the hardest possible route.
>
> True, but it's what I need to do. Unless there's some
> other JSP trick that I'm missing...
>
>
>
> -AndyC
I do this with servlets. In my webapps, all the URLs are handled by
servlets, not JSPs (so all the complicated logic is in Java, and JSPs
are used to display the results). Every servlet has to end with a
forward to a JSP file, and that's where it selects the JSP based on
the current style. Like this:
String someJSPFile = [whatever];
RequestDispatcher rd = request.getRequestDispatcher(someJSPFile);
rd.forward(request, response);
If you've already implemmented the guts of the app in JSP pages, you
could use a small servlet (or filter or JSP) just as a "gateway" to
select which JSP to call.
--
Len
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Bending Jasper to My Will
Shouldn't you be able to do this with most of the web frameworks out
there (like struts, spring MVC, etc). Many of them work by forwarding
all requests to an "action" servlet. The servlet then decides what
action to perform and what jsp to forward the request to. Is there a
reason why you can't use one of those frameworks and extend the "action"
servlet to forward the request to the correct jsp?
-Original Message-
From: Andy Clark [mailto:[EMAIL PROTECTED]
Sent: Monday, April 21, 2008 1:44 PM
To: users@tomcat.apache.org
Subject: Re: Bending Jasper to My Will
Pid wrote:
> Andy Clark wrote:
>> I want Jasper to look for JSP and Tag files in a
>> specific location (e.g. based on a request param);
>> and then fall back to a default location if the
>> file is not found. This would be extremely useful
>> for skinning a webapp.
>
> Cascading Style Sheets are an even more useful,
> practical and easier to implement solution for
> skinning a webapp.
>
> Failing that, programmatically customising the HTML
> output of a common set of tag files would be easier.
CSS and DHTML only applies to the client-side and
does not allow server-side customizations. We need
to go beyond simple color changes or even changing
the HTML layout; we need to be able to override any
or all tags and JSP files in parallel. In other
words, multiple versions of the code is deployed and
we want to control which application code to use
based on the user's settings.
Our application allows users to host multiple domains
and different user levels, each of which can have a
different skin. And we currently allow simple changes
to color, etc via CSS. But if the skin author wants to
change the functionality or layout, they must modify
the base JSP files/tags. Which means that *all* of
the skins see the changes. Not what we want.
For our customers, it is important to be able to
brand each skin independently and even control which
features are exposed via the interface. And we have
no way of knowing all the different ways in which the
customer wants to modify the application. And... they
should be able to do all of this without modifying
the web.xml file.
So what I would like to be able to do (transparently
from the user) is to, on a request-by-request basis,
determine which tags/JSP files to use based on that
user's skin preference. For example, if the user's
skin is set to "Foo", then I want to look for tag and
JSP file overrides in the skins/Foo/ directory and
use those; if I don't find them there, I want to
fallback and use the tags/JSP files in the default
directory.
I'll use a more precise example. Say that I have the
following files in my webapp:
WEB-INF/tags/view.tag
WEB-INF/tags/button.tag
skins/Foo/tags/view.tag
skins/Bar/tags/button.tag
with these contents:
<%-- file: WEB-INF/tags/view.tag --%>
Hello World
<%-- file: WEB-INF/tags/button.tag --%>
<%@ attribute name='text' required='true' %>
${text}
<%-- file: skins/Foo/tags/view.tag --%>
Welcome to Clicky McClicker's Clicktastic Emporium
<%-- file: skins/Bar/tags/button.tag --%>
<%@ attribute name='text' required='true' %>
${text}
If there are three users whose skin preference is
set to , Foo, and Bar, respectively, then
the interface they see is completely different when
the JSP they hit uses in the page.
User 1 sees:
Hello World
Click Me
User 2 sees:
Welcome to Clicky McClicker's Clicktastic Emporium
Clickity Click
User 3 sees:
Hello World
Click Me
In essence, I need to control Jasper internally to
do two things:
1) resolve all requests for tag/JSP files at the
requested location to look for the same file in
the user's skin directory; and
2) failing to find the file in the first location,
try again at the default location.
I hope this sheds some more light on what I need to
do. And I really hope there are some Jasper experts
on the list that can point me in the right direction
(even if it means patching the Jasper source).
> Customising a web app by implementing different sets
> of tag files seems like the hardest possible route.
True, but it's what I need to do. Unless there's some
other JSP trick that I'm missing...
-AndyC
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
The information contained in this transmission is intended only for
the personal and confidential use of the designated recipients named
herein. If the reader of this transmission is not the intended
recipient or an agent respo
Re: Bending Jasper to My Will
2008/4/19, Andy Clark <[EMAIL PROTECTED]>: > I want Jasper to look for JSP and Tag files in a > specific location (e.g. based on a request param); > and then fall back to a default location if the > file is not found. This would be extremely useful > for skinning a webapp. Must you really use JSP? I think that you can achieve this task easier with Velocitye or FreeMarker. In particular, FreeMarker supports JSP tag libraries, and you can load templates from everywhere. For example, Velocity is used in several portal servers (e.g. Liferay). Antonio - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bending Jasper to My Will
Pid wrote:
Andy Clark wrote:
I want Jasper to look for JSP and Tag files in a
>> specific location (e.g. based on a request param);
>> and then fall back to a default location if the
>> file is not found. This would be extremely useful
for skinning a webapp.
Cascading Style Sheets are an even more useful,
> practical and easier to implement solution for
> skinning a webapp.
>
> Failing that, programmatically customising the HTML
> output of a common set of tag files would be easier.
CSS and DHTML only applies to the client-side and
does not allow server-side customizations. We need
to go beyond simple color changes or even changing
the HTML layout; we need to be able to override any
or all tags and JSP files in parallel. In other
words, multiple versions of the code is deployed and
we want to control which application code to use
based on the user's settings.
Our application allows users to host multiple domains
and different user levels, each of which can have a
different skin. And we currently allow simple changes
to color, etc via CSS. But if the skin author wants to
change the functionality or layout, they must modify
the base JSP files/tags. Which means that *all* of
the skins see the changes. Not what we want.
For our customers, it is important to be able to
brand each skin independently and even control which
features are exposed via the interface. And we have
no way of knowing all the different ways in which the
customer wants to modify the application. And... they
should be able to do all of this without modifying
the web.xml file.
So what I would like to be able to do (transparently
from the user) is to, on a request-by-request basis,
determine which tags/JSP files to use based on that
user's skin preference. For example, if the user's
skin is set to "Foo", then I want to look for tag and
JSP file overrides in the skins/Foo/ directory and
use those; if I don't find them there, I want to
fallback and use the tags/JSP files in the default
directory.
I'll use a more precise example. Say that I have the
following files in my webapp:
WEB-INF/tags/view.tag
WEB-INF/tags/button.tag
skins/Foo/tags/view.tag
skins/Bar/tags/button.tag
with these contents:
<%-- file: WEB-INF/tags/view.tag --%>
Hello World
<%-- file: WEB-INF/tags/button.tag --%>
<%@ attribute name='text' required='true' %>
${text}
<%-- file: skins/Foo/tags/view.tag --%>
Welcome to Clicky McClicker's Clicktastic Emporium
<%-- file: skins/Bar/tags/button.tag --%>
<%@ attribute name='text' required='true' %>
${text}
If there are three users whose skin preference is
set to , Foo, and Bar, respectively, then
the interface they see is completely different when
the JSP they hit uses in the page.
User 1 sees:
Hello World
Click Me
User 2 sees:
Welcome to Clicky McClicker's Clicktastic Emporium
Clickity Click
User 3 sees:
Hello World
Click Me
In essence, I need to control Jasper internally to
do two things:
1) resolve all requests for tag/JSP files at the
requested location to look for the same file in
the user's skin directory; and
2) failing to find the file in the first location,
try again at the default location.
I hope this sheds some more light on what I need to
do. And I really hope there are some Jasper experts
on the list that can point me in the right direction
(even if it means patching the Jasper source).
Customising a web app by implementing different sets
> of tag files seems like the hardest possible route.
True, but it's what I need to do. Unless there's some
other JSP trick that I'm missing...
-AndyC
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bending Jasper to My Will
Sounds like you have a lot of bending work ahead of you If you need a quicker solution I would look at implementing the getahead package which uses DWR specifically the setStyle method populates css tags e.g. id setStyle(java.lang.String elementId, java.lang.String selector, java.lang.String value) /*** Sets a CSS style on an element * @param elementId The HTML element to update (by id) * @param selector The CSS selector to update * @param value The new value for the CSS class on the given element */ http://getahead.org/dwr-javadoc/org/directwebremoting/proxy/dwr/Util.html HTH Martin - Original Message - From: "Pid" <[EMAIL PROTECTED]> To: "Tomcat Users List" Sent: Saturday, April 19, 2008 4:33 AM Subject: Re: Bending Jasper to My Will > Andy Clark wrote: > > I have been going through the Jasper source code > > to figure out how to make it do what I want but > > have been unsuccessful. So I thought I would ask > > the experts. (Please let me know if there is a > > better forum for this particular question.) > > > > I want Jasper to look for JSP and Tag files in a > > specific location (e.g. based on a request param); > > and then fall back to a default location if the > > file is not found. This would be extremely useful > > for skinning a webapp. > > Cascading Style Sheets are an even more useful, practical and easier to > implement solution for skinning a webapp. > > Failing that, programmatically customising the HTML output of a common > set of tag files would be easier. > > Customising a web app by implementing different sets of tag files seems > like the hardest possible route. > > What requirement would make this a necessity? > > p > > > > > > Any ideas? > > > > -AndyC > > > > - > > To start a new topic, e-mail: users@tomcat.apache.org > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > - > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bending Jasper to My Will
Andy Clark wrote: I have been going through the Jasper source code to figure out how to make it do what I want but have been unsuccessful. So I thought I would ask the experts. (Please let me know if there is a better forum for this particular question.) I want Jasper to look for JSP and Tag files in a specific location (e.g. based on a request param); and then fall back to a default location if the file is not found. This would be extremely useful for skinning a webapp. Cascading Style Sheets are an even more useful, practical and easier to implement solution for skinning a webapp. Failing that, programmatically customising the HTML output of a common set of tag files would be easier. Customising a web app by implementing different sets of tag files seems like the hardest possible route. What requirement would make this a necessity? p Any ideas? -AndyC - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Bending Jasper to My Will
I have been going through the Jasper source code to figure out how to make it do what I want but have been unsuccessful. So I thought I would ask the experts. (Please let me know if there is a better forum for this particular question.) I want Jasper to look for JSP and Tag files in a specific location (e.g. based on a request param); and then fall back to a default location if the file is not found. This would be extremely useful for skinning a webapp. Any ideas? -AndyC - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
