[long] Why building Spindle is hard Pt.3

Ok. We have shown that Tapestry Pages and Components can exist in more
than one namespace and that in come bizarre application setups it can
lead to runtime errors.

Why does this make building tools for tapestry harder?

Tapestry is like a dynamic language (pick one Python/Perl/Ruby)
everything is resolved as late as possible. The Tapestry runtime does
not care if things exist in one, two, or umtine namespaces. The app
will work fine unless a configuration like the one above is
encountered. Some may say this makes Tapestry more flexible, I don't
share that sentiment.

From a tool standpoint it makes life very difficult but nor
insurmountable. An IDE is by it's very nature a static representation
of the application. It is possible to figure out all the namespaces
that a page or component might exist in but how useful is that to an
IDE user? I mean beyond pointing out the fact that a Page or Component
has many parents (and that can cause problems).

It's my view that supporting the fact of page/component existing in
muliple namespaces makes Spindle a LESS useful tool:

Validation: do we validate a particular file in context of every
namespace it exists in? This could potentially cause a line in a file
to have multiple, conflicting error messages:

Component not found + missing required parameter

what the heck?

It's worse for editor features as at the time of editing there is no
way to know which namespace the user thinks they are working in...

Syntax completion:

<span jwcid="@Message" ^/> hit crtl-space on the ^

The offered suggestions could include conflicting suggestions. Both
implementations of Message in the example war have a parameter called
'foo' one is required and one is not required. How does one present
that to the user?

Performance:
  if one is going to validate a component in the context of all
namespaces it exists in we are taking a multiple hit, perform the same
validation multiple times. Computing syntax completions takes a
similar hit as does JumpTo.

Complexity - Spindle's implementation of IComponentSpecification has a
reference to the 'owner' namespace. One could change the
implementation to include all of the names but the impact on other
parts of the tool, like incremental validation are unknown.

As I said in the first email, Tapestry has always had this 'feature'.
Choices were made in the past to mitigate the impact.

For one, an early choice was made to ignore the fact that pages and
components may exist in multiple namespaces.

At some point before Tapestry 3 (I don't recall exact versions/dates)
there were no hierarchical namespaces (libraries) and all
pages/component had to be explicitly declared using .page/.jwc files
and using <page>, <component-*> tags in X.application.

All .page, .jwc, and template files lived in the classpath and there
was no chance for the problem to occur.


Spindle was *much* simpler then and ignoring was acceptable.

The hierarchical namespace implementation introduced in Tapestry 2 but
Spindle didn't get religion until Tapestry 3 came out. But, everything
still lived in the classpath and the chance that a user would
accidentally include a page/component in more than one namespace was
minute. In fact, if it happened it was usually by choice and with full
knowledge of any consequences.

Tried to keep ignoring the problem in Spindle 2.X for T3 but several
things in Tapestry 3 made adjustments necessary:

- the application namespace (file) moved out of the classpath and into
the context.

- Explicit declaration of things using <page> and <component-type>
tags became optional. This made it much more likely that someone could
accidentally include a page or component in more than one namespace.

- having the application namespace in the context meant that if
multiple Tapestry application were located in a jar file it was
virtually *assured* that things would end up living in multiple
namespaces if the developer was not careful.

- the Tapestry version of "Specless Pages" was such that all specless
pages automatically existed in all application namespaces (multiple
Tapestry apps per war).

- lastly, the concept of a project builder/validator and context aware
xml editors were introduced into Spindle

All this meant that Spindle could no longer ignore the problem.

Well, sort of. Further choices were made.

- An Eclipse Tapestry project could contain only one Tapestry
application. This eliminated 90+% of all the cases where the problem
would occur.

- Spindle would continue to ignore multiple namespace problems for
libraries (they still existed in the classpath - low probability of
problem occurrence).

So, in Spindle 2.X it was possible that the problem could occur, but
the likely hood was low and the visible impact was very low. An odd
weird error marker or completion suggestion.

In Tapestry 3.0.2 or 3.0.3 it became possible to host a library in the
context. Oops, now we are back to the case I eliminated when I
restricted Tapestry Projects to one application. At first I missed the
change altogether and by the time I added a tweak to support it work
had already begun on Spindle 4T4 so this is supported but no handled
well in the existing plug-in.

So, in summary, over the last 3 emails I have described the side
effect, given an example, explained the example and outline the
choices made in the Spindle implementation (to date) to deal with the
side effect problem.

In the next email I'll describe how this side effect + the new
features in Tapestry 4 make the implementation of Spindle *extremely*
difficult.

Fasten your seat belts, It's going to be bumpy.

Geoff


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642