Progress report on Spindle support for Tapestry 2.4

[Geoff Longman <gl...@intelligentworks.com>]

It was a productive weekend despite my son's colic and the invasion of my
family..

created a new plugin called TapestryValidator (which will be renamed
spindle.core eventually).

The new plugin defines a new Tapestry flavour of project that drops the
restriction of one application/library per project.
Its more of a helper flavour in that its less than "first class" like a Java
Project. Rather it connects the validator to
an existing project. Wizards are not required (although they will appear
eventually) to add this flavour. Basically, one can
select any Java Project and in its properties specify that its a Tapestry
project.

The property page allows one to optionally specify/create folders that the
validator (core) will look for application root and servlet context root
(/WEB-INF). these are optional because in the case that the project contains
no applications, they are ignored. In the case that the project contains
applications, at least servlet context root is required as the plugin needs
to find and parse web.xml to locate the application(s).

Also, have built the beginnings of a Tapestry project builder. This builder
runs after the Java builder. Eclipse builders sometimes will perform full or
incremental builds. Right now the Tapestry builder only performs full builds
(incremental builds will come later).

As for the full builds, this is just getting started. Right now, the full
build checks to see if it can run (unresolved classpath issues found by the
Java builder is one example where it won't run), and performs the following
steps:

1. locates web.xml and parses it (if it exists), collecting all the servlet
declarations. Validation errors on web.xml show up as error markers in
Eclipse and parsing stops. (Note that if web.xml is not found or is not
parseable, the builder will treat the project as if there are no
applications!)

That's it so far (quite a bit of work to get this far). As the work
continues, the builder will do the following...

2. examine the servlets found and toss out any that are not
org.apache.tapestry.ApplicationServlet (or subclasses thereof)

3. For valid servlets, consume the init parameters and record the
information in some structure.

4. Traverse the project and find all Tapestry artifacts (.page, .jwc, .html,
.application, .library files), mark and discard any found that are in
folders that are not found in/under:

application root
servlet contextroot (/WEB-INF).
source folders
jar files/dependant projects (binary classpath)

5. Collect the libraries in a structure similar to that used above to record
the applications.

6. Using the results of 3 & 5, traverse the collection found in 4 and relate
all .page, .html (that are "pages"), and jwc files to thier owner
applications/libraries. This is the biggest job as it involves all the funky
new rules for locating things.

7. Some artifacts from 4 will not be immediately relatable to owner specs
(ie. things in application root and (/WEB-INF) are visible to all the
applications in the project). These will be kept around without owners for
now. Any stuff outside of application root and /WEB-INF that pass though
step 6 without getting an owner spec will be marked and no longer be
considered by the builder.

8. Now that ownership has been determined, the appropriate Namespaces for
all the application/library specs will be built.

9. parse all the .jwc, .page, and html "pages" checking the following:

if not parseable, mark in error
do all the usual checking that occurs when these files are parsed. mark
errors as appropriate
resolve and record the references from pages and components to thier
contained components, assets, templates.
Templates get thier "owner specs" in this operation.
Mark as errors any references above that can't be resolved.
parse any templates found (recording errors as appropriate)

10. store the state (apps, libs, namespaces, references) for use in future
incremental builds. This state will also be used in the future by the
Spindle editors.

Lots of work, and that's before any GUI stuff like wizards and editors. The
output of this initial work will be a plugin that one can use
without any Spindle editors, it will sit quietly attached to the project and
mark Tapestry related errors/warnings.

Geoff

Geoffrey Longman
Intelligent Works Inc.

RE: Progress report on Spindle support for Tapestry 2.4

["Howard M. Lewis Ship" <hl...@attbi.com>]

You are THE MAN!

--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/proposals/tapestry



> -----Original Message-----
> From: Geoff Longman [mailto:glongman@intelligentworks.com] 
> Sent: Monday, March 10, 2003 6:54 AM
> To: spindle-developer@lists.sourceforge.net
> Cc: spindle-user@lists.sourceforge.net; Tapestry users
> Subject: Progress report on Spindle support for Tapestry 2.4
> 
> 
> It was a productive weekend despite my son's colic and the 
> invasion of my family..
> 
> created a new plugin called TapestryValidator (which will be 
> renamed spindle.core eventually).
> 
> The new plugin defines a new Tapestry flavour of project that 
> drops the restriction of one application/library per project. 
> Its more of a helper flavour in that its less than "first 
> class" like a Java Project. Rather it connects the validator 
> to an existing project. Wizards are not required (although 
> they will appear
> eventually) to add this flavour. Basically, one can
> select any Java Project and in its properties specify that 
> its a Tapestry project.
> 
> The property page allows one to optionally specify/create 
> folders that the validator (core) will look for application 
> root and servlet context root (/WEB-INF). these are optional 
> because in the case that the project contains no 
> applications, they are ignored. In the case that the project 
> contains applications, at least servlet context root is 
> required as the plugin needs to find and parse web.xml to 
> locate the application(s).
> 
> Also, have built the beginnings of a Tapestry project 
> builder. This builder runs after the Java builder. Eclipse 
> builders sometimes will perform full or incremental builds. 
> Right now the Tapestry builder only performs full builds 
> (incremental builds will come later).
> 
> As for the full builds, this is just getting started. Right 
> now, the full build checks to see if it can run (unresolved 
> classpath issues found by the Java builder is one example 
> where it won't run), and performs the following
> steps:
> 
> 1. locates web.xml and parses it (if it exists), collecting 
> all the servlet declarations. Validation errors on web.xml 
> show up as error markers in Eclipse and parsing stops. (Note 
> that if web.xml is not found or is not parseable, the builder 
> will treat the project as if there are no
> applications!)
> 
> That's it so far (quite a bit of work to get this far). As 
> the work continues, the builder will do the following...
> 
> 2. examine the servlets found and toss out any that are not 
> org.apache.tapestry.ApplicationServlet (or subclasses thereof)
> 
> 3. For valid servlets, consume the init parameters and record 
> the information in some structure.
> 
> 4. Traverse the project and find all Tapestry artifacts 
> (.page, .jwc, .html, .application, .library files), mark and 
> discard any found that are in folders that are not found in/under:
> 
> application root
> servlet contextroot (/WEB-INF).
> source folders
> jar files/dependant projects (binary classpath)
> 
> 5. Collect the libraries in a structure similar to that used 
> above to record the applications.
> 
> 6. Using the results of 3 & 5, traverse the collection found 
> in 4 and relate all .page, .html (that are "pages"), and jwc 
> files to thier owner applications/libraries. This is the 
> biggest job as it involves all the funky new rules for 
> locating things.
> 
> 7. Some artifacts from 4 will not be immediately relatable to 
> owner specs (ie. things in application root and (/WEB-INF) 
> are visible to all the applications in the project). These 
> will be kept around without owners for now. Any stuff outside 
> of application root and /WEB-INF that pass though step 6 
> without getting an owner spec will be marked and no longer be 
> considered by the builder.
> 
> 8. Now that ownership has been determined, the appropriate 
> Namespaces for all the application/library specs will be built.
> 
> 9. parse all the .jwc, .page, and html "pages" checking the following:
> 
> if not parseable, mark in error
> do all the usual checking that occurs when these files are 
> parsed. mark errors as appropriate resolve and record the 
> references from pages and components to thier contained 
> components, assets, templates. Templates get thier "owner 
> specs" in this operation. Mark as errors any references above 
> that can't be resolved. parse any templates found (recording 
> errors as appropriate)
> 
> 10. store the state (apps, libs, namespaces, references) for 
> use in future incremental builds. This state will also be 
> used in the future by the Spindle editors.
> 
> Lots of work, and that's before any GUI stuff like wizards 
> and editors. The output of this initial work will be a plugin 
> that one can use without any Spindle editors, it will sit 
> quietly attached to the project and mark Tapestry related 
> errors/warnings.
> 
> Geoff
> 
> Geoffrey Longman
> Intelligent Works Inc.
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>