On May 15, 2005, at 7:15 PM, Mind Bridge wrote:
A few comments:
- I actually think that minimizing the number of link components is a very
good thing. My examples were simply taking into account the status quo, but
I do think this is a good direction to move in. In fact, DirectLink,
ActionLink, PageLink, and ExternalLink could relatively easily be folded
into a single Link component (e.g. by making 'page' optional as well, etc).
That will greatly simplify the amount of material a new Tapestry user would
have to learn and will open up some new, albeit unconventional possibilities
(e.g. execute a listener in another page)
Yay, consensus on this one!
As it stands, at the moment one has to learn Tapestry, HTML, XML, and Java
in order to be achieve something with the framework.
That's just barely scratching the surface of what a developer needs to know to be proficient with Tapestry (or any other Java web framework for that matter).
Adding aspects to the
mix (and the proper way to use them as there are lots of improper ways),
would be unnecessarily painful. I feel that we should come up with an easy
way to achieve transitions with a minimum of Java code involved and without
the necessity of another framework. Even experienced Java users would
appreciate an easy solution for something they code over and over again.
Aspects are a possibility for implementation, but I am not sure they should
be exposed to the general user.
To clarify - when I say "aspects" I don't mean any particular technology. And in the case of Howard's recent change to Tapestry 4.0, the aspecting technology for listener method wrapping is a HiveMind pipeline.
I have tinkered with AspectJ and had prototype success with doing _around_ aspecting of listener methods as well.
Whether the aspect nature of things is built into the framework or not is an interesting architectural decision. Should the framework be more complex and have built-in hooks for everything or should the framework be simpler and leave aspects up to another technology like AspectJ? I prefer simpler pieces that can be constructed in complex ways if I like but the complexity is up to me as a developer using the frameworks, and having the frameworks themselves be simpler.
Perhaps I am misunderstanding what you mean... Could you give an example?
The use case for listener aspects for me is to wrap them with a DB transaction boundary - commit or rollback after a listener is invoked based on whether the listener succeeded or not. A listener succeeding is a tricky thing to determine though with the use of two flow control exceptions mucking it up.
- Using the finate set of HTML attrubites in Direct links as informal
parameter, and make everything else properties:
I do not like this method for the following reasons:
a) That set of attributes will possibly expand with the next version of
HTML/XHTML
b) Some of the HTML attributes are logical property names
c) You may want to have attributes outside of this set -- they make no sense
in HTML, but the Javascript of the page may do something with them.
I agree with these points. But with c) the non-standard attributes really should be namespaced, especially to be compliant to XHTML.
My point is from the most modern XHTML spec point of view, and is more idealistic than Tapestry ought to be.
- Just a side note: There is a difference between parameters and properties.
As I see it, parameters are a part of the public contract of the
page/component. Properties, on the other hand, are a part of the private
contract. When you modify your page, you can rearrange your properties to
your heart content as there are very few files affected. On the other hand
you have to take great care of modifying your public interface as lots of
other pages may rely on it (and often you do not even know what they are).
This is especially true when there is no static verification as it is in
Tapestry.
I have noticed that in the web world there is little appreciation of the
difference between public and private interface, probably because there is
low instant gratification. This only becomes critical (and not following the
principle quite painful) in big applications. Nevertheless, I think we
should try to follow this distinction when we can.
These are good points about public interfaces to pages.
Also, this is one possible difference between tying to properties in
DirectLink and ExternalLink -- in the former case they could be any property
as this is a local call, in the latter they should be parameters, as the
call is remote... If there is unification, however, it probably makes sense
to limit both to parameters.
more good points! The distinction between the local call with DirectLink and "remote" call with ExternalLink is important and whether the rewind is part of the equation or not.
Sorry, I am a bit pressed for time at the moment and cannot respond to all
of your question
Same here.
Erik
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
