You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Laurie Harper <zo...@holoweb.net> on 2003/10/09 04:15:22 UTC
organising pages
I must be missing something here :-) How do I reference pages in a
sub-directory? For example, if I have .../webapps/app/login/login.html,
how to I reference that with PageLink?
I tried the obvious:
<span jwcid="@PageLink" page="login/login.html">Login</span>
but the '/' doesn't get encoded and seems to confuse Tapestry's request
processing. Please feel free to tell me to RTFM -- just point me to the
right one :-)
L.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: organising pages
Posted by Vince Marco <vm...@mac.com>.
I agree with your philosophy on this. However, not at the limitation of
my configurability. I prefer IDEA to Eclipse (at least for now) and
don't use Spindle on a regular basis. But the XML isn't difficult
either. It would be nice if I had a plugin to track and tell me when my
configs were out of wack, but generally this isn't a problem. Designing
a path for ease of use should not sacrifice flexibility.
If you want to make this even easier, then let me specify separate
content and config folders in the .application file as an alternative to
specifying each page and component. I disklike tying page loading to
the classpath as not only is it elusive and problematic as is (perhaps
the most problematic aspect of Java), but many developers will fail to
make the connection between templates/XML files and the Java classpath.
Why not let them configure these locations explicitly for dynamic
loading of config and content files?
Vince
Howard M. Lewis Ship wrote:
>>As I see it a Spindle-like tool could
>>reduce the
>>extra effort very effectively, and I'd rather a tool automate
>>explicit
>>organization than lazy organization anyday.
>>
>>
>>
>
>Managing the .application file was a big complaint for many. I would like to avoid it if possible. I
>prefer to avoid solutions that mandate tool support ... prior to Spindle and 3.0 I frequently
>explained that all the XML wasn't an issue because we were just waiting for proper tool support.
>Even with Spindle (which only helps Eclipse users) my attitude has shifted. Unlike JSF, Tapestry
>should be completely useable with simple, off-the-shelf tools ... standard HTML editors and IDEs.
>
>--
>Howard M. Lewis Ship
>Creator, Tapestry: Java Web Components
>http://jakarta.apache.org/tapestry
>http://jakarta.apache.org/commons/sandbox/hivemind/
>http://javatapestry.blogspot.com
>
>
>---------------------------------------------------------------------
>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: organising pages
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
> As I see it a Spindle-like tool could
> reduce the
> extra effort very effectively, and I'd rather a tool automate
> explicit
> organization than lazy organization anyday.
>
Managing the .application file was a big complaint for many. I would like to avoid it if possible. I
prefer to avoid solutions that mandate tool support ... prior to Spindle and 3.0 I frequently
explained that all the XML wasn't an issue because we were just waiting for proper tool support.
Even with Spindle (which only helps Eclipse users) my attitude has shifted. Unlike JSF, Tapestry
should be completely useable with simple, off-the-shelf tools ... standard HTML editors and IDEs.
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: organising pages
Posted by Vince Marco <vm...@mac.com>.
I don't use option A. I do use option B. I create a WEB-INF/config
folder for all specs, and a WEB-INF/content for all templates. I only
have to expose the content folder to prototypers / web designers and
with that as the site root and an external images folder, looks like a
normal static site within DreamWeaver.
I don't mind modifying the .application file as I deploy as a .war file
anyway. Sure it's a bit more effort than not, but I think it is more
maintainable. New developers have a complete list of components and
pages right in the .application file. I guess it depends on your
definition of optimal. As I see it a Spindle-like tool could reduce the
extra effort very effectively, and I'd rather a tool automate explicit
organization than lazy organization anyday.
Vince
>_Option A_
>Place .html and .page files in the application root (or other specified
>location). No sub directories are allowed.
>
>_Option B_
>Place .html and .page files on the class path and list each page in the
>.application file.
>
>As I see it, neither of these options are optimal. Option A results in
>an entire application in one directory. Option B results in an
>inflexible application in which each page addition to the site requires
>modifying the .application file, which requires a restart and is a bit
>tedious.
>
>Comments?
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: organising pages
Posted by Colin Sampaleanu <co...@exis.com>.
But unless I'm missing something, this doesn't help resolve the relative
image link issue. If you are in your source, and previewing something,
images will be at a different relative location than when running inside
Tapestry...
Bryan Lewis wrote:
>Sorry to come to the party so late, but I'm unclear on something here.
>
>Why is Option A so bad? It's only for the deployment layout -- the structure of the war file -- and that's not designed for human consumption anyway. Your source tree can be laid out any old way you please. Your ant build file does the remapping, of course.
>
>Typical source tree:
>
>+--src
> \--intranet
> +--common
> +--conf
> \--view
> +--home // each dir contains the html/page/java trilogy
> +--tabbedmenu
> \--and so on for every page
> \--web // with images, css, .application, static htmls
>
>
>Deployment image (war):
>
>+--index.html // static html files in root
>+--META-INF
>\--WEB-INF
> +--Home.html // *.page and html templates
> +--Home.page
> +--TabbedMenu.html
> +--TabbedMenu.jwc
> +--classes
> | \--intranet
> | +--common
> | \--view
> | +--home
> | | \--Home.class // just the classes, ma'am
> | \--tabbedmenu
> | \--TabbedMenu.class
> \--web.xml
>
>Now that's only my preference for a source tree. My little development group has only programmers, no designers, so we don't care about separating the content. (I tried to imitate the jakarta cvs tree, actually.) But if we wanted to separate the html we could, merely by modifying the buildfile. The deployment image wouldn't change at all.
>
>Yes, I have seen some examples where people made their source layout similar to the deployment layout, with directory names like META-INF and WEB-INF. (You ever try typing those names in a hurry?!?) I hope that's not the norm.
>
>
>----- Original Message -----
>From: "Eric Everman" <ev...@precedadesign.com>
>To: "Tapestry users" <ta...@jakarta.apache.org>
>Sent: Thursday, October 09, 2003 11:36 AM
>Subject: Re: organising pages
>
>
>
>
>>Not So Fast!
>>
>>This question actually gets at one of my hang-ups with Tapestry. As I
>>see it, you have two options to organize a web site.
>>
>>_Option A_
>>Place .html and .page files in the application root (or other specified
>>location). No sub directories are allowed.
>>
>>_Option B_
>>Place .html and .page files on the class path and list each page in the
>>.application file.
>>
>>As I see it, neither of these options are optimal. Option A results in
>>an entire application in one directory. Option B results in an
>>inflexible application in which each page addition to the site requires
>>modifying the .application file, which requires a restart and is a bit
>>tedious.
>>
>>Comments?
>>
>>Eric Everman
>>
>>On Thu, 2003-10-09 at 10:35, Mindaugas Genutis wrote:
>>
>>
>>>The correct reference is this:
>>>
>>><span jwcid="@PageLink" page="login">Login</span>
>>>
>>>Documentation:
>>>
>>>http://jakarta.apache.org/tapestry/doc/ComponentReference/PageLink.html
>>>
>>>
>>>
>>>><span jwcid="@PageLink" page="login/login.html">Login</span>
>>>>
>>>>but the '/' doesn't get encoded and seems to confuse Tapestry's request
>>>>processing. Please feel free to tell me to RTFM -- just point me to the
>>>>right one :-)
>>>>
>>>>L.
>>>>
>>>>
>>>>
>>>>---------------------------------------------------------------------
>>>>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: organising pages
Posted by Vince Marco <vm...@mac.com>.
Your not late, your right on time. I didn't say Option A was
bad.....just that I don't use it. Here are my preferences:
- keep all Tapestry files underneath WEB-INF rather than webapp root.
This way they are protected from direct access.
- avoid putting html templates and configs directly in WEB-INF root.
This makes finding my web.xml and web.application quick and easy.
- separate config and html template files into separate folders
(WEB-INF/config, WEB-INF/content). This last makes it easier for me to
find files. It also enables me to create a soft link to the content
folder and the images folder and point Dreamweaver to the HTML templates
and not have to sift through the .jwc and .page files when navigating
the site.
It works very well as the site scales up.....at least for me. :-)
Vince
Bryan Lewis wrote:
>Sorry to come to the party so late, but I'm unclear on something here.
>
>Why is Option A so bad? It's only for the deployment layout -- the structure of the war file -- and that's not designed for human consumption anyway. Your source tree can be laid out any old way you please. Your ant build file does the remapping, of course.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: organising pages
Posted by Bryan Lewis <br...@maine.rr.com>.
Sorry to come to the party so late, but I'm unclear on something here.
Why is Option A so bad? It's only for the deployment layout -- the structure of the war file -- and that's not designed for human consumption anyway. Your source tree can be laid out any old way you please. Your ant build file does the remapping, of course.
Typical source tree:
+--src
\--intranet
+--common
+--conf
\--view
+--home // each dir contains the html/page/java trilogy
+--tabbedmenu
\--and so on for every page
\--web // with images, css, .application, static htmls
Deployment image (war):
+--index.html // static html files in root
+--META-INF
\--WEB-INF
+--Home.html // *.page and html templates
+--Home.page
+--TabbedMenu.html
+--TabbedMenu.jwc
+--classes
| \--intranet
| +--common
| \--view
| +--home
| | \--Home.class // just the classes, ma'am
| \--tabbedmenu
| \--TabbedMenu.class
\--web.xml
Now that's only my preference for a source tree. My little development group has only programmers, no designers, so we don't care about separating the content. (I tried to imitate the jakarta cvs tree, actually.) But if we wanted to separate the html we could, merely by modifying the buildfile. The deployment image wouldn't change at all.
Yes, I have seen some examples where people made their source layout similar to the deployment layout, with directory names like META-INF and WEB-INF. (You ever try typing those names in a hurry?!?) I hope that's not the norm.
----- Original Message -----
From: "Eric Everman" <ev...@precedadesign.com>
To: "Tapestry users" <ta...@jakarta.apache.org>
Sent: Thursday, October 09, 2003 11:36 AM
Subject: Re: organising pages
> Not So Fast!
>
> This question actually gets at one of my hang-ups with Tapestry. As I
> see it, you have two options to organize a web site.
>
> _Option A_
> Place .html and .page files in the application root (or other specified
> location). No sub directories are allowed.
>
> _Option B_
> Place .html and .page files on the class path and list each page in the
> .application file.
>
> As I see it, neither of these options are optimal. Option A results in
> an entire application in one directory. Option B results in an
> inflexible application in which each page addition to the site requires
> modifying the .application file, which requires a restart and is a bit
> tedious.
>
> Comments?
>
> Eric Everman
>
> On Thu, 2003-10-09 at 10:35, Mindaugas Genutis wrote:
> > The correct reference is this:
> >
> > <span jwcid="@PageLink" page="login">Login</span>
> >
> > Documentation:
> >
> > http://jakarta.apache.org/tapestry/doc/ComponentReference/PageLink.html
> >
> > > <span jwcid="@PageLink" page="login/login.html">Login</span>
> > >
> > > but the '/' doesn't get encoded and seems to confuse Tapestry's request
> > > processing. Please feel free to tell me to RTFM -- just point me to the
> > > right one :-)
> > >
> > > L.
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> > >
> --
> Preceda Design LLC
> www.precedadesign.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
Re: organising pages
Posted by Laurie Harper <zo...@holoweb.net>.
Oops, my bad! I wasn't trying to use <span
jwcid="@foo.components.widget"/> in the component, but rather <frame
jwcid="@Frame" page="@foo.components.widget"/>. With or without the '@'
it fails. Any hints?
Thanks,
L.
Laurie Harper wrote:
> Eric Everman wrote:
>
>> Not So Fast!
>>
>> This question actually gets at one of my hang-ups with Tapestry. As I
>> see it, you have two options to organize a web site.
>>
>> _Option A_
>> Place .html and .page files in the application root (or other specified
>> location). No sub directories are allowed.
>>
>> _Option B_
>> Place .html and .page files on the class path and list each page in the
>> .application file.
>
>
> Ugh, I think you answered my question: I can't do what I wanted within
> Option A. I'll play with Option B and see how 'natural' it ends up feeling.
>
> I've run into another problem working with Option A: not being able to
> use sub-directories, I wanted to use a naming convention to get some
> organisation. So I started out with this:
>
> root
> + WEB-INF
> | + app1
> | | + auth.login.page
> | | + foo.somepage.page
> | ...
> + app1
> | + auth.login.html
> | + auth.logout.html
> | + foo.somepage.html
> ...
>
> I didn't realise I could put the html files alongside the page files
> under WEB-INF, that cleans things up a bit :-) The above worked until I
> tried to create some components:
>
>
> root
> + WEB-INF
> | + app1
> | | + foo.components.widget.html
> | | + foo.components.widget.jwc
> | | + foo.somepage.page
> | ...
> + app1
> | + foo.somepage.html
> ...
>
> where foo.somepage.html had a <span jwcid="@foo.components.widget"/> in
> it. The first problem was that the jwc file seems to be required even if
> I don't have anything to put in it. I also haven't figured out how to
> avoid having multiple identical jwc files if I want several components
> to have, say, the same stylesheet asset defined. I'm guessing I can work
> round that by using my own class extending BaseComponent and having that
> define such common data, though.
>
> What turned out to be a bit more limitting, though, was that Tapestry
> rejected foo.components.widget as a valid component name. I tried every
> seperator I could think of (every punctuation character on my keyboard
> ;-). The only thing that seems to work is '_'. At least that worked
> though :-) I should probably switch the naming convention for the page
> files to match though. I've run into restrictions on other things too,
> such as asset names. Some of these would probably be obvious if I
> understood what was going on under the covers; I'm just getting started
> right now.
>
> Definately seems, at this point, like I should try using classpath-based
> organisation instead. It's going to get awful messy as it scales up
> using this approach! If anyone has any alternative suggestions or
> pointers let me know.
>
> Now I'm trying to figure out why I can't reference one component from
> another. That is, if I put <span jwcid="@foo.components.widget"/> in a
> page file it works but if I put it in a component html file it doesn't.
> Please tell me if this can't be done either so I can save my head and/or
> the well I beating with it :-)
>
> Sorry for the verbosity; I'm just getting my feet wet so far, but I'm
> starting to believe I'll be able to swim by the time I get in deep enough!
>
> L.
>
>
>
> ---------------------------------------------------------------------
> 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: organising pages
Posted by Laurie Harper <zo...@holoweb.net>.
Eric Everman wrote:
> Not So Fast!
>
> This question actually gets at one of my hang-ups with Tapestry. As I
> see it, you have two options to organize a web site.
>
> _Option A_
> Place .html and .page files in the application root (or other specified
> location). No sub directories are allowed.
>
> _Option B_
> Place .html and .page files on the class path and list each page in the
> .application file.
Ugh, I think you answered my question: I can't do what I wanted within
Option A. I'll play with Option B and see how 'natural' it ends up feeling.
I've run into another problem working with Option A: not being able to
use sub-directories, I wanted to use a naming convention to get some
organisation. So I started out with this:
root
+ WEB-INF
| + app1
| | + auth.login.page
| | + foo.somepage.page
| ...
+ app1
| + auth.login.html
| + auth.logout.html
| + foo.somepage.html
...
I didn't realise I could put the html files alongside the page files
under WEB-INF, that cleans things up a bit :-) The above worked until I
tried to create some components:
root
+ WEB-INF
| + app1
| | + foo.components.widget.html
| | + foo.components.widget.jwc
| | + foo.somepage.page
| ...
+ app1
| + foo.somepage.html
...
where foo.somepage.html had a <span jwcid="@foo.components.widget"/> in
it. The first problem was that the jwc file seems to be required even if
I don't have anything to put in it. I also haven't figured out how to
avoid having multiple identical jwc files if I want several components
to have, say, the same stylesheet asset defined. I'm guessing I can work
round that by using my own class extending BaseComponent and having that
define such common data, though.
What turned out to be a bit more limitting, though, was that Tapestry
rejected foo.components.widget as a valid component name. I tried every
seperator I could think of (every punctuation character on my keyboard
;-). The only thing that seems to work is '_'. At least that worked
though :-) I should probably switch the naming convention for the page
files to match though. I've run into restrictions on other things too,
such as asset names. Some of these would probably be obvious if I
understood what was going on under the covers; I'm just getting started
right now.
Definately seems, at this point, like I should try using classpath-based
organisation instead. It's going to get awful messy as it scales up
using this approach! If anyone has any alternative suggestions or
pointers let me know.
Now I'm trying to figure out why I can't reference one component from
another. That is, if I put <span jwcid="@foo.components.widget"/> in a
page file it works but if I put it in a component html file it doesn't.
Please tell me if this can't be done either so I can save my head and/or
the well I beating with it :-)
Sorry for the verbosity; I'm just getting my feet wet so far, but I'm
starting to believe I'll be able to swim by the time I get in deep enough!
L.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: organising pages
Posted by Colin Sampaleanu <co...@exis.com>.
Howard M. Lewis Ship wrote:
>>Well, I think the best that can be done with base tags is to
>>use relative urls. So if you are two levels out of your root
>>directory, you could use:
>>
>>[base href="../../"]
>>
>>
>>
>
>I aggree ... if that works; if I remember correctly, the href in a <base> tag should
>always be a complete URL. If we can fudge that a little using an WYSIWYG editor, so much the
>better, given
>that we'll strip out the <base> tag at runtime.
>
>So far, HomeSite 4.0 doesn't allow this, but newer version (4.5) or Dreamweaver might.
>
>
>
Unfortunately it's definitely not legal, and doesn't seem to work
anywhere I've tried it. The actual document path has to be absolute:
http://www.w3.org/TR/REC-html40/struct/links.html#h-12.4
Now reading the RFC you'd possibly think even the host/port need to be
specified. As far as I can tell with every browser I've tried, you can
skip those and it will use the values from the original document, but
the actual path can't be relative.
What might work in some build environments, is a token that gets
replaced with an absolute value during the build. I work with source and
target dirs even for the web site, so this would work for me, but would
mean I would have to look at all html files in the target dir...
>--
>Howard M. Lewis Ship
>Creator, Tapestry: Java Web Components
>http://jakarta.apache.org/tapestry
>http://jakarta.apache.org/commons/sandbox/hivemind/
>http://javatapestry.blogspot.com
>
>
>---------------------------------------------------------------------
>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: organising pages
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
>
> Well, I think the best that can be done with base tags is to
> use relative urls. So if you are two levels out of your root
> directory, you could use:
>
> [base href="../../"]
>
I aggree ... if that works; if I remember correctly, the href in a <base> tag should
always be a complete URL. If we can fudge that a little using an WYSIWYG editor, so much the
better, given
that we'll strip out the <base> tag at runtime.
So far, HomeSite 4.0 doesn't allow this, but newer version (4.5) or Dreamweaver might.
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: organising pages
Posted by Eric Everman <ev...@precedadesign.com>.
Well, I think the best that can be done with base tags is to use
relative urls. So if you are two levels out of your root directory, you
could use:
[base href="../../"]
Of course, people would have the option of hard-coding the server name
into their base tags, but I don't plan to be one of them :)
Eric Everman
On Thu, 2003-10-09 at 13:00, Howard M. Lewis Ship wrote:
> So far using (good old) HomeSite 4.0, I can only accomplish this with a hard-coded <base> path:
>
> <base href="file://c:/Temp/">
> or
> <base href="c:/Temp/">
>
>
> That's far, far less than ideal (!) but it's a start. Perhaps newer tools are smarter. I'll have
> to download some demos and see.
>
> --
> Howard M. Lewis Ship
> Creator, Tapestry: Java Web Components
> http://jakarta.apache.org/tapestry
> http://jakarta.apache.org/commons/sandbox/hivemind/
> http://javatapestry.blogspot.com
>
> > -----Original Message-----
> > From: Eric Everman [mailto:everman@precedadesign.com]
> > Sent: Thursday, October 09, 2003 12:33 PM
> > To: Tapestry users
> > Subject: RE: organising pages
> >
> >
> > One thought I had for pages in the app root directory was to
> > 'require' the <base> tag for previewing pages, not for deploying them.
> >
> > For instance, a page located at approot/login/login.html
> > might contain this html:
> >
> > ==============================
> > [html]
> > [head][base href="../"][/head]
> >
> > [span jwcid="$content$"]
> > ...content follows
> > ==============================
> >
> > If we then allow undeclared pages to be referenced with a
> > path notation, this page could be accessed something like
> > page="login/login".
> >
> > The benefit would be that undeclared pages could be organized
> > into sub-folders. The catch is that full previews would
> > require a base tag in the removed portion of the template.
> > Full preview with images always requires some work, however,
> > as we need to add dummy image href's under any scheme.
> >
> >
> > Eric Everman
> >
> >
> >
> > On Thu, 2003-10-09 at 10:58, Howard M. Lewis Ship wrote:
> > > I agree that A and B have problems.
> > >
> > > I want to balance these against the idea that relative URLs
> > to images
> > > work when previewing.
> > >
> > > Currently, the HTML for a page is at /root/Page.html
> > > The Tapestry applet is at /root/app
> > > Therefore the base URL is /root/
> > > So that relative paths in the template (i.e., images/splash.gif)
> > > convert to /root/images/splash.gif. End effect: preview in
> > editor same
> > > as runtime ... good!
> > >
> > > Now, what if we allow "complex" page names, such as "login/Login".
> > >
> > > HTML template ends up in /root/login/Login.html
> > > When previewing, you need to use ../images/splash.gif
> > > That becomes /images/splash.gif (not the needed
> > > /root/images/splash.gif) so that breaks at runtime.
> > >
> > > I tried, in the past, to have the Shell component emit a
> > <base> tag,
> > > but many apps behind firewalls broke.
> > >
> > > Perhaps Tapestry needs to change to use the other servlet mapping.
> > >
> > > So, URLs might look like:
> > >
> > > http://..../root/Home.app?service=direct/foo
> > >
> > > or
> > >
> > > http://..../root/login/Login.app (assume service is 'page' I would
> > > think).
> > >
> > > Problem: a listener method on Login.app does:
> > >
> > > cycle.activate("deep/dark/Subpage");
> > >
> > > Base URL: /root/login/
> > > HTML template: /root/deep/dark/Subpage.html
> > >
> > > Again ... we get big problems with relative asset paths (in
> > the static
> > > portion of the HTML template). Do we require that every
> > <img> become
> > > an Image component? Ugh. Do we require that static HTML templates
> > > hard code the context root (i.e., always say
> > > "/root/images/splash.gif"). This means we must deploy as
> > "root.war"
> > > (or otherwise map the context to "/root"). Again ... ugh.
> > >
> > > I'm still spinning what a good solution for this would look
> > like. I
> > > keep coming back to the <base> tag ... there are hooks in
> > Tapestry to
> > > override the default way it determines what the base URL is, which
> > > would be necessary for deployed apps behind a firewall.
> > Still, there
> > > are further interactions involving URLs in JavaScript (for example).
> > >
> > > I do acknowledge that something needs to be done (in the 3.1
> > > timeframe). I think we could end up with shorter, sweeter
> > URLs if we
> > > can just solve the problems related to relative URLs in the static
> > > HTML.
> > >
> > >
> > > --
> > > Howard M. Lewis Ship
> > > Creator, Tapestry: Java Web Components
> > > http://jakarta.apache.org/tapestry
> > > http://jakarta.apache.org/commons/sandbox/hivemind/
> > > http://javatapestry.blogspot.com
> > >
> > > > -----Original Message-----
> > > > From: Eric Everman [mailto:everman@precedadesign.com]
> > > > Sent: Thursday, October 09, 2003 11:37 AM
> > > > To: Tapestry users
> > > > Subject: Re: organising pages
> > > >
> > > >
> > > > Not So Fast!
> > > >
> > > > This question actually gets at one of my hang-ups with
> > > > Tapestry. As I see it, you have two options to organize
> > a web site.
> > > >
> > > > _Option A_
> > > > Place .html and .page files in the application root (or other
> > > > specified location). No sub directories are allowed.
> > > >
> > > > _Option B_
> > > > Place .html and .page files on the class path and list each
> > > > page in the .application file.
> > > >
> > > > As I see it, neither of these options are optimal. Option A
> > > > results in an entire application in one directory. Option B
> > > > results in an inflexible application in which each page
> > > > addition to the site requires modifying the .application
> > > > file, which requires a restart and is a bit tedious.
> > > >
> > > > Comments?
> > > >
> > > > Eric Everman
> > > >
> > > > On Thu, 2003-10-09 at 10:35, Mindaugas Genutis wrote:
> > > > > The correct reference is this:
> > > > >
> > > > > <span jwcid="@PageLink" page="login">Login</span>
> > > > >
> > > > > Documentation:
> > > > >
> > > > >
> > > > http://jakarta.apache.org/tapestry/doc/Compone>
> > > > ntReference/PageLink.htm
> > > > > l
> > > > >
> > > > > > <span jwcid="@PageLink" page="login/login.html">Login</span>
> > > > > >
> > > > > > but the '/' doesn't get encoded and seems to confuse
> > Tapestry's
> > > > > > request
> > > > > > processing. Please feel free to tell me to RTFM -- just
> > > > point me to the
> > > > > > right one :-)
> > > > > >
> > > > > > L.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > >
> > --------------------------------------------------------------------
> > > > > > -
> > > > > > To unsubscribe, e-mail:
> > > > tapestry-user-unsubscribe@jakarta.apache.org
> > > > > > For additional commands, e-mail:
> > > > tapestry-user-help@jakarta.apache.org
> > > > > >
> > > > --
> > > > Preceda Design LLC
> > > > www.precedadesign.com
> > > >
> > > >
> > > >
> > --------------------------------------------------------------------
> > > > -
> > > > 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
> > --
> > Preceda Design LLC
> > www.precedadesign.com
> >
> >
> > ---------------------------------------------------------------------
> > 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
--
Preceda Design LLC
www.precedadesign.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: organising pages
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
So far using (good old) HomeSite 4.0, I can only accomplish this with a hard-coded <base> path:
<base href="file://c:/Temp/">
or
<base href="c:/Temp/">
That's far, far less than ideal (!) but it's a start. Perhaps newer tools are smarter. I'll have
to download some demos and see.
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com
> -----Original Message-----
> From: Eric Everman [mailto:everman@precedadesign.com]
> Sent: Thursday, October 09, 2003 12:33 PM
> To: Tapestry users
> Subject: RE: organising pages
>
>
> One thought I had for pages in the app root directory was to
> 'require' the <base> tag for previewing pages, not for deploying them.
>
> For instance, a page located at approot/login/login.html
> might contain this html:
>
> ==============================
> [html]
> [head][base href="../"][/head]
>
> [span jwcid="$content$"]
> ...content follows
> ==============================
>
> If we then allow undeclared pages to be referenced with a
> path notation, this page could be accessed something like
> page="login/login".
>
> The benefit would be that undeclared pages could be organized
> into sub-folders. The catch is that full previews would
> require a base tag in the removed portion of the template.
> Full preview with images always requires some work, however,
> as we need to add dummy image href's under any scheme.
>
>
> Eric Everman
>
>
>
> On Thu, 2003-10-09 at 10:58, Howard M. Lewis Ship wrote:
> > I agree that A and B have problems.
> >
> > I want to balance these against the idea that relative URLs
> to images
> > work when previewing.
> >
> > Currently, the HTML for a page is at /root/Page.html
> > The Tapestry applet is at /root/app
> > Therefore the base URL is /root/
> > So that relative paths in the template (i.e., images/splash.gif)
> > convert to /root/images/splash.gif. End effect: preview in
> editor same
> > as runtime ... good!
> >
> > Now, what if we allow "complex" page names, such as "login/Login".
> >
> > HTML template ends up in /root/login/Login.html
> > When previewing, you need to use ../images/splash.gif
> > That becomes /images/splash.gif (not the needed
> > /root/images/splash.gif) so that breaks at runtime.
> >
> > I tried, in the past, to have the Shell component emit a
> <base> tag,
> > but many apps behind firewalls broke.
> >
> > Perhaps Tapestry needs to change to use the other servlet mapping.
> >
> > So, URLs might look like:
> >
> > http://..../root/Home.app?service=direct/foo
> >
> > or
> >
> > http://..../root/login/Login.app (assume service is 'page' I would
> > think).
> >
> > Problem: a listener method on Login.app does:
> >
> > cycle.activate("deep/dark/Subpage");
> >
> > Base URL: /root/login/
> > HTML template: /root/deep/dark/Subpage.html
> >
> > Again ... we get big problems with relative asset paths (in
> the static
> > portion of the HTML template). Do we require that every
> <img> become
> > an Image component? Ugh. Do we require that static HTML templates
> > hard code the context root (i.e., always say
> > "/root/images/splash.gif"). This means we must deploy as
> "root.war"
> > (or otherwise map the context to "/root"). Again ... ugh.
> >
> > I'm still spinning what a good solution for this would look
> like. I
> > keep coming back to the <base> tag ... there are hooks in
> Tapestry to
> > override the default way it determines what the base URL is, which
> > would be necessary for deployed apps behind a firewall.
> Still, there
> > are further interactions involving URLs in JavaScript (for example).
> >
> > I do acknowledge that something needs to be done (in the 3.1
> > timeframe). I think we could end up with shorter, sweeter
> URLs if we
> > can just solve the problems related to relative URLs in the static
> > HTML.
> >
> >
> > --
> > Howard M. Lewis Ship
> > Creator, Tapestry: Java Web Components
> > http://jakarta.apache.org/tapestry
> > http://jakarta.apache.org/commons/sandbox/hivemind/
> > http://javatapestry.blogspot.com
> >
> > > -----Original Message-----
> > > From: Eric Everman [mailto:everman@precedadesign.com]
> > > Sent: Thursday, October 09, 2003 11:37 AM
> > > To: Tapestry users
> > > Subject: Re: organising pages
> > >
> > >
> > > Not So Fast!
> > >
> > > This question actually gets at one of my hang-ups with
> > > Tapestry. As I see it, you have two options to organize
> a web site.
> > >
> > > _Option A_
> > > Place .html and .page files in the application root (or other
> > > specified location). No sub directories are allowed.
> > >
> > > _Option B_
> > > Place .html and .page files on the class path and list each
> > > page in the .application file.
> > >
> > > As I see it, neither of these options are optimal. Option A
> > > results in an entire application in one directory. Option B
> > > results in an inflexible application in which each page
> > > addition to the site requires modifying the .application
> > > file, which requires a restart and is a bit tedious.
> > >
> > > Comments?
> > >
> > > Eric Everman
> > >
> > > On Thu, 2003-10-09 at 10:35, Mindaugas Genutis wrote:
> > > > The correct reference is this:
> > > >
> > > > <span jwcid="@PageLink" page="login">Login</span>
> > > >
> > > > Documentation:
> > > >
> > > >
> > > http://jakarta.apache.org/tapestry/doc/Compone>
> > > ntReference/PageLink.htm
> > > > l
> > > >
> > > > > <span jwcid="@PageLink" page="login/login.html">Login</span>
> > > > >
> > > > > but the '/' doesn't get encoded and seems to confuse
> Tapestry's
> > > > > request
> > > > > processing. Please feel free to tell me to RTFM -- just
> > > point me to the
> > > > > right one :-)
> > > > >
> > > > > L.
> > > > >
> > > > >
> > > > >
> > > > >
> > >
> --------------------------------------------------------------------
> > > > > -
> > > > > To unsubscribe, e-mail:
> > > tapestry-user-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail:
> > > tapestry-user-help@jakarta.apache.org
> > > > >
> > > --
> > > Preceda Design LLC
> > > www.precedadesign.com
> > >
> > >
> > >
> --------------------------------------------------------------------
> > > -
> > > 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
> --
> Preceda Design LLC
> www.precedadesign.com
>
>
> ---------------------------------------------------------------------
> 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: organising pages
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
That's a very cool idea; handicap the rule breakers (throw who put their HTML templates outside the
expected location, the root folder), keep it compatible with tools, leverage jwcid="$remove$" to fix
things.
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com
> -----Original Message-----
> From: Eric Everman [mailto:everman@precedadesign.com]
> Sent: Thursday, October 09, 2003 12:33 PM
> To: Tapestry users
> Subject: RE: organising pages
>
>
> One thought I had for pages in the app root directory was to
> 'require' the <base> tag for previewing pages, not for deploying them.
>
> For instance, a page located at approot/login/login.html
> might contain this html:
>
> ==============================
> [html]
> [head][base href="../"][/head]
>
> [span jwcid="$content$"]
> ...content follows
> ==============================
>
> If we then allow undeclared pages to be referenced with a
> path notation, this page could be accessed something like
> page="login/login".
>
> The benefit would be that undeclared pages could be organized
> into sub-folders. The catch is that full previews would
> require a base tag in the removed portion of the template.
> Full preview with images always requires some work, however,
> as we need to add dummy image href's under any scheme.
>
>
> Eric Everman
>
>
>
> On Thu, 2003-10-09 at 10:58, Howard M. Lewis Ship wrote:
> > I agree that A and B have problems.
> >
> > I want to balance these against the idea that relative URLs
> to images
> > work when previewing.
> >
> > Currently, the HTML for a page is at /root/Page.html
> > The Tapestry applet is at /root/app
> > Therefore the base URL is /root/
> > So that relative paths in the template (i.e., images/splash.gif)
> > convert to /root/images/splash.gif. End effect: preview in
> editor same
> > as runtime ... good!
> >
> > Now, what if we allow "complex" page names, such as "login/Login".
> >
> > HTML template ends up in /root/login/Login.html
> > When previewing, you need to use ../images/splash.gif
> > That becomes /images/splash.gif (not the needed
> > /root/images/splash.gif) so that breaks at runtime.
> >
> > I tried, in the past, to have the Shell component emit a
> <base> tag,
> > but many apps behind firewalls broke.
> >
> > Perhaps Tapestry needs to change to use the other servlet mapping.
> >
> > So, URLs might look like:
> >
> > http://..../root/Home.app?service=direct/foo
> >
> > or
> >
> > http://..../root/login/Login.app (assume service is 'page' I would
> > think).
> >
> > Problem: a listener method on Login.app does:
> >
> > cycle.activate("deep/dark/Subpage");
> >
> > Base URL: /root/login/
> > HTML template: /root/deep/dark/Subpage.html
> >
> > Again ... we get big problems with relative asset paths (in
> the static
> > portion of the HTML template). Do we require that every
> <img> become
> > an Image component? Ugh. Do we require that static HTML templates
> > hard code the context root (i.e., always say
> > "/root/images/splash.gif"). This means we must deploy as
> "root.war"
> > (or otherwise map the context to "/root"). Again ... ugh.
> >
> > I'm still spinning what a good solution for this would look
> like. I
> > keep coming back to the <base> tag ... there are hooks in
> Tapestry to
> > override the default way it determines what the base URL is, which
> > would be necessary for deployed apps behind a firewall.
> Still, there
> > are further interactions involving URLs in JavaScript (for example).
> >
> > I do acknowledge that something needs to be done (in the 3.1
> > timeframe). I think we could end up with shorter, sweeter
> URLs if we
> > can just solve the problems related to relative URLs in the static
> > HTML.
> >
> >
> > --
> > Howard M. Lewis Ship
> > Creator, Tapestry: Java Web Components
> > http://jakarta.apache.org/tapestry
> > http://jakarta.apache.org/commons/sandbox/hivemind/
> > http://javatapestry.blogspot.com
> >
> > > -----Original Message-----
> > > From: Eric Everman [mailto:everman@precedadesign.com]
> > > Sent: Thursday, October 09, 2003 11:37 AM
> > > To: Tapestry users
> > > Subject: Re: organising pages
> > >
> > >
> > > Not So Fast!
> > >
> > > This question actually gets at one of my hang-ups with
> > > Tapestry. As I see it, you have two options to organize
> a web site.
> > >
> > > _Option A_
> > > Place .html and .page files in the application root (or other
> > > specified location). No sub directories are allowed.
> > >
> > > _Option B_
> > > Place .html and .page files on the class path and list each
> > > page in the .application file.
> > >
> > > As I see it, neither of these options are optimal. Option A
> > > results in an entire application in one directory. Option B
> > > results in an inflexible application in which each page
> > > addition to the site requires modifying the .application
> > > file, which requires a restart and is a bit tedious.
> > >
> > > Comments?
> > >
> > > Eric Everman
> > >
> > > On Thu, 2003-10-09 at 10:35, Mindaugas Genutis wrote:
> > > > The correct reference is this:
> > > >
> > > > <span jwcid="@PageLink" page="login">Login</span>
> > > >
> > > > Documentation:
> > > >
> > > >
> > > http://jakarta.apache.org/tapestry/doc/Compone>
> > > ntReference/PageLink.htm
> > > > l
> > > >
> > > > > <span jwcid="@PageLink" page="login/login.html">Login</span>
> > > > >
> > > > > but the '/' doesn't get encoded and seems to confuse
> Tapestry's
> > > > > request
> > > > > processing. Please feel free to tell me to RTFM -- just
> > > point me to the
> > > > > right one :-)
> > > > >
> > > > > L.
> > > > >
> > > > >
> > > > >
> > > > >
> > >
> --------------------------------------------------------------------
> > > > > -
> > > > > To unsubscribe, e-mail:
> > > tapestry-user-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail:
> > > tapestry-user-help@jakarta.apache.org
> > > > >
> > > --
> > > Preceda Design LLC
> > > www.precedadesign.com
> > >
> > >
> > >
> --------------------------------------------------------------------
> > > -
> > > 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
> --
> Preceda Design LLC
> www.precedadesign.com
>
>
> ---------------------------------------------------------------------
> 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: organising pages
Posted by Eric Everman <ev...@precedadesign.com>.
One thought I had for pages in the app root directory was to 'require'
the <base> tag for previewing pages, not for deploying them.
For instance, a page located at approot/login/login.html might contain
this html:
==============================
[html]
[head][base href="../"][/head]
[span jwcid="$content$"]
...content follows
==============================
If we then allow undeclared pages to be referenced with a path notation,
this page could be accessed something like page="login/login".
The benefit would be that undeclared pages could be organized into
sub-folders. The catch is that full previews would require a base tag
in the removed portion of the template. Full preview with images always
requires some work, however, as we need to add dummy image href's under
any scheme.
Eric Everman
On Thu, 2003-10-09 at 10:58, Howard M. Lewis Ship wrote:
> I agree that A and B have problems.
>
> I want to balance these against the idea that relative URLs to images work when previewing.
>
> Currently, the HTML for a page is at /root/Page.html
> The Tapestry applet is at /root/app
> Therefore the base URL is /root/
> So that relative paths in the template (i.e., images/splash.gif) convert to /root/images/splash.gif.
> End effect: preview in editor same as runtime ... good!
>
> Now, what if we allow "complex" page names, such as "login/Login".
>
> HTML template ends up in /root/login/Login.html
> When previewing, you need to use ../images/splash.gif
> That becomes /images/splash.gif (not the needed /root/images/splash.gif) so that breaks at runtime.
>
> I tried, in the past, to have the Shell component emit a <base> tag, but many apps behind firewalls
> broke.
>
> Perhaps Tapestry needs to change to use the other servlet mapping.
>
> So, URLs might look like:
>
> http://..../root/Home.app?service=direct/foo
>
> or
>
> http://..../root/login/Login.app (assume service is 'page' I would think).
>
> Problem: a listener method on Login.app does:
>
> cycle.activate("deep/dark/Subpage");
>
> Base URL: /root/login/
> HTML template: /root/deep/dark/Subpage.html
>
> Again ... we get big problems with relative asset paths (in the static portion of the HTML
> template).
> Do we require that every <img> become an Image component? Ugh.
> Do we require that static HTML templates hard code the context root (i.e., always say
> "/root/images/splash.gif"). This means we must deploy as "root.war" (or otherwise map the context
> to "/root"). Again ... ugh.
>
> I'm still spinning what a good solution for this would look like. I keep coming back to the <base>
> tag ... there are hooks in Tapestry to override the default way it determines what the base URL is,
> which would be necessary for deployed apps behind a firewall. Still, there are further interactions
> involving URLs in JavaScript (for example).
>
> I do acknowledge that something needs to be done (in the 3.1 timeframe). I think we could end up
> with shorter, sweeter URLs if we can just solve the problems related to relative URLs in the static
> HTML.
>
>
> --
> Howard M. Lewis Ship
> Creator, Tapestry: Java Web Components
> http://jakarta.apache.org/tapestry
> http://jakarta.apache.org/commons/sandbox/hivemind/
> http://javatapestry.blogspot.com
>
> > -----Original Message-----
> > From: Eric Everman [mailto:everman@precedadesign.com]
> > Sent: Thursday, October 09, 2003 11:37 AM
> > To: Tapestry users
> > Subject: Re: organising pages
> >
> >
> > Not So Fast!
> >
> > This question actually gets at one of my hang-ups with
> > Tapestry. As I see it, you have two options to organize a web site.
> >
> > _Option A_
> > Place .html and .page files in the application root (or other
> > specified location). No sub directories are allowed.
> >
> > _Option B_
> > Place .html and .page files on the class path and list each
> > page in the .application file.
> >
> > As I see it, neither of these options are optimal. Option A
> > results in an entire application in one directory. Option B
> > results in an inflexible application in which each page
> > addition to the site requires modifying the .application
> > file, which requires a restart and is a bit tedious.
> >
> > Comments?
> >
> > Eric Everman
> >
> > On Thu, 2003-10-09 at 10:35, Mindaugas Genutis wrote:
> > > The correct reference is this:
> > >
> > > <span jwcid="@PageLink" page="login">Login</span>
> > >
> > > Documentation:
> > >
> > >
> > http://jakarta.apache.org/tapestry/doc/Compone> ntReference/PageLink.htm
> > > l
> > >
> > > > <span jwcid="@PageLink" page="login/login.html">Login</span>
> > > >
> > > > but the '/' doesn't get encoded and seems to confuse Tapestry's
> > > > request
> > > > processing. Please feel free to tell me to RTFM -- just
> > point me to the
> > > > right one :-)
> > > >
> > > > L.
> > > >
> > > >
> > > >
> > > >
> > --------------------------------------------------------------------
> > > > -
> > > > To unsubscribe, e-mail:
> > tapestry-user-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail:
> > tapestry-user-help@jakarta.apache.org
> > > >
> > --
> > Preceda Design LLC
> > www.precedadesign.com
> >
> >
> > ---------------------------------------------------------------------
> > 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
--
Preceda Design LLC
www.precedadesign.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: organising pages
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
I agree that A and B have problems.
I want to balance these against the idea that relative URLs to images work when previewing.
Currently, the HTML for a page is at /root/Page.html
The Tapestry applet is at /root/app
Therefore the base URL is /root/
So that relative paths in the template (i.e., images/splash.gif) convert to /root/images/splash.gif.
End effect: preview in editor same as runtime ... good!
Now, what if we allow "complex" page names, such as "login/Login".
HTML template ends up in /root/login/Login.html
When previewing, you need to use ../images/splash.gif
That becomes /images/splash.gif (not the needed /root/images/splash.gif) so that breaks at runtime.
I tried, in the past, to have the Shell component emit a <base> tag, but many apps behind firewalls
broke.
Perhaps Tapestry needs to change to use the other servlet mapping.
So, URLs might look like:
http://..../root/Home.app?service=direct/foo
or
http://..../root/login/Login.app (assume service is 'page' I would think).
Problem: a listener method on Login.app does:
cycle.activate("deep/dark/Subpage");
Base URL: /root/login/
HTML template: /root/deep/dark/Subpage.html
Again ... we get big problems with relative asset paths (in the static portion of the HTML
template).
Do we require that every <img> become an Image component? Ugh.
Do we require that static HTML templates hard code the context root (i.e., always say
"/root/images/splash.gif"). This means we must deploy as "root.war" (or otherwise map the context
to "/root"). Again ... ugh.
I'm still spinning what a good solution for this would look like. I keep coming back to the <base>
tag ... there are hooks in Tapestry to override the default way it determines what the base URL is,
which would be necessary for deployed apps behind a firewall. Still, there are further interactions
involving URLs in JavaScript (for example).
I do acknowledge that something needs to be done (in the 3.1 timeframe). I think we could end up
with shorter, sweeter URLs if we can just solve the problems related to relative URLs in the static
HTML.
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com
> -----Original Message-----
> From: Eric Everman [mailto:everman@precedadesign.com]
> Sent: Thursday, October 09, 2003 11:37 AM
> To: Tapestry users
> Subject: Re: organising pages
>
>
> Not So Fast!
>
> This question actually gets at one of my hang-ups with
> Tapestry. As I see it, you have two options to organize a web site.
>
> _Option A_
> Place .html and .page files in the application root (or other
> specified location). No sub directories are allowed.
>
> _Option B_
> Place .html and .page files on the class path and list each
> page in the .application file.
>
> As I see it, neither of these options are optimal. Option A
> results in an entire application in one directory. Option B
> results in an inflexible application in which each page
> addition to the site requires modifying the .application
> file, which requires a restart and is a bit tedious.
>
> Comments?
>
> Eric Everman
>
> On Thu, 2003-10-09 at 10:35, Mindaugas Genutis wrote:
> > The correct reference is this:
> >
> > <span jwcid="@PageLink" page="login">Login</span>
> >
> > Documentation:
> >
> >
> http://jakarta.apache.org/tapestry/doc/Compone> ntReference/PageLink.htm
> > l
> >
> > > <span jwcid="@PageLink" page="login/login.html">Login</span>
> > >
> > > but the '/' doesn't get encoded and seems to confuse Tapestry's
> > > request
> > > processing. Please feel free to tell me to RTFM -- just
> point me to the
> > > right one :-)
> > >
> > > L.
> > >
> > >
> > >
> > >
> --------------------------------------------------------------------
> > > -
> > > To unsubscribe, e-mail:
> tapestry-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
> tapestry-user-help@jakarta.apache.org
> > >
> --
> Preceda Design LLC
> www.precedadesign.com
>
>
> ---------------------------------------------------------------------
> 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: organising pages
Posted by Eric Everman <ev...@precedadesign.com>.
Not So Fast!
This question actually gets at one of my hang-ups with Tapestry. As I
see it, you have two options to organize a web site.
_Option A_
Place .html and .page files in the application root (or other specified
location). No sub directories are allowed.
_Option B_
Place .html and .page files on the class path and list each page in the
.application file.
As I see it, neither of these options are optimal. Option A results in
an entire application in one directory. Option B results in an
inflexible application in which each page addition to the site requires
modifying the .application file, which requires a restart and is a bit
tedious.
Comments?
Eric Everman
On Thu, 2003-10-09 at 10:35, Mindaugas Genutis wrote:
> The correct reference is this:
>
> <span jwcid="@PageLink" page="login">Login</span>
>
> Documentation:
>
> http://jakarta.apache.org/tapestry/doc/ComponentReference/PageLink.html
>
> > <span jwcid="@PageLink" page="login/login.html">Login</span>
> >
> > but the '/' doesn't get encoded and seems to confuse Tapestry's request
> > processing. Please feel free to tell me to RTFM -- just point me to the
> > right one :-)
> >
> > L.
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> >
--
Preceda Design LLC
www.precedadesign.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: Question about a DirectLink property.
Posted by David Solis <ds...@legosoft.com.mx>.
Hi Marc,
If you don't understand how to use it, then I guess you don't need it
:-).
Speaking seriously, with a custom ILinkRenderer you can have other kind
of links, e.g. GoLinkRederer is used to render a WML "go" instead of an
HTML "a" element.
Example:
<go jwcid="@ServiceLink"
service="ognl:@org.apache.tapestry.Tapestry@HOME_SERVICE"
renderer="ognl:@org.apache.tapestry.wml.GoLinkRenderer@SHARED_INSTANCE"
href=""/>
To emit a WML go element to the Home page.
Other cases could be: AreaLinkRenderer for area elements of an image
map, PopupLinkRenderer for popup windows, etc.
Regards
D.
> -----Original Message-----
> From: Mark Alcocer Flores [mailto:superpchead@yahoo.com]
> Sent: Thursday, October 09, 2003 1:39 PM
> To: Tapestry users
> Subject: Question about a DirectLink property.
>
> Hello everyone,
>
> I am using the DirectLink component but i don't
> undesatand how to use the renderer parameter. Can
> anyone give me an example of how it is supose to be
> used?
>
> Mark
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Question about a DirectLink property.
Posted by Mark Alcocer Flores <su...@yahoo.com>.
Hello everyone,
I am using the DirectLink component but i don't
undesatand how to use the renderer parameter. Can
anyone give me an example of how it is supose to be
used?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: organising pages
Posted by Mindaugas Genutis <mi...@elinara.ktu.lt>.
The correct reference is this:
<span jwcid="@PageLink" page="login">Login</span>
Documentation:
http://jakarta.apache.org/tapestry/doc/ComponentReference/PageLink.html
> <span jwcid="@PageLink" page="login/login.html">Login</span>
>
> but the '/' doesn't get encoded and seems to confuse Tapestry's request
> processing. Please feel free to tell me to RTFM -- just point me to the
> right one :-)
>
> L.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
--
Kaunas Regional Distance Education Center
Programmer
Phone: +370 674 05232
WWW: http://distance.ktu.lt
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org