FIRST PART:I like the idea for a default application name & recursive search for pages under a certain hierarchy. Though I'm not sure how you search for resources.
I don't have enough experience with the types of sites that the second part addresses to comment.
-----Original Message-----
From: Sacha Labourey [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 24, 2002 2:28 PM
To: Tapestry-Developer ML
Subject: [Tapestry-developer] Suggestions for Tapestry (long post)
Hello,
I've read the numerous posts about simplifying access to Tapestry for simple
projects. I'd like to contribute some constructive ideas on this topic
(without generating to much heat though, if that's possible...)
First of all, please be sure that I really understand why some people are
affraid loosing Tapestry's strength, typing, etc.: all the ideas I will
propose are lead by two goals:
- to simplify Tapestry's use for small projects (or for prototypes)
- to work more easily with "verbose" web sites (I will explain that below)
BTW, sorry for the long post (it is not intended to test DB2's CLOBs
@sf.net)
SMALL PROJECTS
==============
While I agree that the overhead of a few .application and .page files is
negligible for most projects, I also think that this overhead is not really
necessary (and annoying) for really quick prototyping.
We could very easily imagine to reduce this overhead without sacrifying the
current (advised) behaviour. I start...
1�) ApplicationServlet
Today, Howard commited a change so that the servlet definition could include
the path/name of the xxx.application file and thus, for simple applications,
it is not necessary to implement a new servlet just to give this
information. I think that is a really good thing.
Nevertheless, I think we should go further and that by default,
ApplicationServlet should use, for its
"net.sf.tapestry.application-specification" parameter, the value
"/default.application" (or any other name)
And it would answer Howard's wink saying "Seems like its just as much typing
as creating a subclass". ;)
As EJBs have a default META-INF/ejb-jar.xml file, I don't see what is
terrifying about having a default .application name (that you can override!)
2�) xxx.application file
The xxx.application file mainly defines an application name, an engine
class, a visit object and a set of pages.
Most of the time, the most cumbersome thing to do is to list all pages in a
set of <page> attributes. Consequently, why not add a new tag such as
<pages> i.e.
<!-- explicit method -->
<page name="Home" specification-path="/tutorial/hangman/Home.page"/>
<!-- NEW implicit method -->
<pages dir="/com/here/foo" matches="*.page" recursive="yes" />
You will ask me "what about the page name now?!?". Well, we could simply
define it in the xxx.page file directly i.e.
<page-specification class="tutorial.hangman.Home" page-name="Home" >
^^^^^^^^^^
or use the file name directly (but I am sure you won't like it) ;)
This way, the xxx.application file can be very simply while making xxx.pages
only slightly more complex.
To recursivly find all *.pages file, ServletContext.getResourcePaths () can
be used.
3�) Totally removing very simple xxx.application files
For very simple prototypes, the xxx.application file doesn't contain any
critical information:
app name (not critical, can be defaulted), engine class (SimpleEngine),
visit object (not necessary).
Only the default set of pages is important. Thus, when no
/default.application file is present, we could default to an implicit
declaration such as:
<application name="Default"
engine-class="net.sf.tapestry.engine.SimpleEngine">
<pages dir="/" matches="*.page" recursive="yes" />
</application>
I am sure this is exactly the kind of behaviour we would implicitly expect
i.e.: I just gave you a few xxx.page files (and their associated xxx.html
file), just use them! Otherwise, it is a little like if you gave your VISA
card to a clerk and the guy would tell you "What do you expect me to do with
it?" (it is obvious: I just want to pay!) It is the same here: I give you a
WAR containing some *.page files, just use them!
==> Conclusion for this first part:
===================================
With these modifications, nothing of the current behaviour is changed. At
the same time, let's see a few scenaris of what could be achieved.
S1:
you could have a simple tapestry application consisting only of this:
/a.page
/a.html
or this:
/my/app/a.page
/my/app/a.html
S2:
If you want to change some info such as setting a visit page:
/default.application
/my/app/a.page
/my/app/a.html
both examples don't need a specific servlet parameters and the second
example defaults to /default.application
For people that don't want these defaults, we can imagine to have a JVM
property (such as "net.sf.tapestry.strict-mode") that can be set to
prohibit/avoid these implicit behaviours.
SECOND PART: VERBOSE SITES
==========================
The second kind of suggestions concern what could be called "verbose" web
site.
What Tapestry is very good at is to deal with user interaction.
Specifically, interaction with forms is really GREAT. Nevertheless, imagine
that what you have, in some part of your web site, is a huge set of
presentation pages such as a full set of documentation (Tapestry doco for
example). In this case, Tapestry is really cumbersome to use.
These (verbose) web sites would still benefit from Tapestry (to mimic
sitemesh behaviour, extract user information from the session in a component
and display it at the top of the page for example, etc.) but writing an
*identical* xxx.page file for *each* xxx.html page is really, really
frustrating.
My suggestion would be to allow many html (sub-)pages to be linked to a
single xxx.page definition. These html would be required to follow some
strict naming conventions such as (let's say we have a "xxx.page" file):
xxx.html (default page)
info.xxx.html
setup.xxx.html
...
Then, when referencing pages, it would be possible to give a PAGE name (as
now) AND an optional name such as "Chapter", "sub-page" or "view". For
example:
<component id="setup" type="PageLink">
<static-binding name="page">xxx</static-binding>
<static-binding name="view">setup</static-binding> <!-- NEW
PARAMETER -->
</component>
Thus, a whole set of pages could be linked to a single xxx.page file. At the
same time, the localization features could still work (by using the same
current naming scheme)
Consequently, part of web sites that only deal with displaying static
information + displaying some session info would be very easy to write.
That's all for today ;)
I would be glad to hear your constructive comments. Cheers,
Sacha
-------------------------------------------------------
This sf.net email is sponsored by: Influence the future
of Java(TM) technology. Join the Java Community
Process(SM) (JCP(SM)) program now.
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0003en
_______________________________________________
Tapestry-developer mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/tapestry-developer
