Hello Howard,
> That's not a terrible idea, that there should be a default
> location for the
> application specification.
Then, specify one ;)
> I'm also thinking that the 1.4 versions of the specifications
> (sorry Geoff)
> will allow the class names for the engine, page and component to
> be omitted
> (defaulting to SimpleEngine, BasePage and BaseComponent, respectively).
Yes, that seems to be very relevant.
> I'm a bit more nervous about the idea of scanning for .pages.
> First off, it
> represents a shift in Tapestry from storing page (and component)
> specifications in the classpath to storing them in the web application
> context (i.e., alongside static HTML and assets). Also, I'm not
> aware of a
> completely portable way to "scan" for files ... you would need to do a bit
> of work to down cast ClassLoader to specific implementations that had the
> necessary methods. I'm not even sure which ClassLoader methods
> I'd need ...
> probably have to get to URLClassLoader, query the URLs, work from there.
> Messy (but doable).
I agree on this point: you change the location where you data is stored, and
this is maybe a too big shift for the Tapestry community. (and
URLClassLoader won't help you on this). At least, if one day we have a
Tapestry sub-deployer in JBoss, this is the kind of things it would be good
at (but this would be a jboss specific optimization)
> Anyway, where I'm headed now is Tapestry Lite, with big flaming warning
> signs, but
> - You can put your HTML files in the web app context (at the root)
> - An "implicit" specification will be generated from such HTML files
> - The HTML file can specify the Java page class
Do you mean the *.page file to which they are linked? Will this address my
"part-II" suggestion? In this case how will your PageLink be specified?
Because I think it is really important to have a way to address this
situation.
> - You can define components (ids, types and bindings) in the HTML (I call
> these "implcit components", vs. the "declared components" of traditional
> Tapestry)
That's is an important feature, I agree.
> - You don't need an app specification (initially)
ok. So, how do you reference pages?
> - You can mix and match Tapestry Lite with traditional Tapestry, so when a
> page becomes too complex to be implicit, you can create a .page for it and
> register the .page in the .application
yes, very important and I really think that the opposite will also very
frequently happen: you have a full fledged Tapestry application (fully
specified), and, for some set of pages, you will ommit the .page. IMHO,
these new features are not "lite", they are just "Shortcuts" and don't
degrade the power of tapestry. It is a strength, not a weakness.
> Also, I think (in the long run) a lot of components are going to "go
> implicit". Components that generally don't take formal
> parameters (such as
> Body) can simply be <body jwcid="@Body"> and be done with it. Likewise,
> most Inserts and Conditional components can be implicit. The downside to
That's seems good. Once again, IMHO, all these modifications bring real
power and flexibility to Tapestry and are not weaknesses. If you want to do
very simple things, then you can; if you want to correctly learn the
framework, then you can; and if you really know the framework, you can have
some flexibility by using some really interesting shortcuts. The real
keywork IMHO is flexibility.
In fact, teaching Tapestry becomes easier aswell: you can start with a
"Tapestry lite" intro, and, step-by-step, show the limitations induced by
using the lite framework, thus introducing step-by-step "Tapestry non-lite"
features such as .application, .page, explicit component definitions, etc.
At the end of the learning process, the newcomer will understand *WHY* you
should define all these files and consequently, in which situation he could
ommit them. Currently, the learning process is not easy because you are
asking new developers to define a lot of things for a very simple example
without a real advantage for it (the overhead is really big). The advantages
only show up when the examples grow and become more complex. (In fact, I am
sure that most of the time the first examples of the tutorial make some
people not use Tapestry and stop reading ;) )
For new users, it will make the adoption and learning process easier and for
old-tapestry-guys, it will make their life easier in many situations.
Sorry to be so verbose. Cheers,
Sacha -v
-------------------------------------------------------
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?sunm0004en
_______________________________________________
Tapestry-developer mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/tapestry-developer
