Howard Lewis Ship wrote:
I agree that <service> was easier than the HM approach, which is
(infinitely) flexible.
Perhaps we just autowire the service instance with properties of
matching type from the Infrastructure service. So, if you need a
LinkFactory in your service, just define a setter method that takes a
LinkFactory parameter.
I made the decision that engine services would use HM because that's a
very uncommon operation in Tapestry, as opposed to creating pages and
components.
I've been struggling with the following choice:
1) Keep backwards compatibility and evolve the code base (give or take)
2) Sacrifice backwards compatibility, but create the simpler, less
ambiguous (easier to learn) framework people want
I'm prototyping some stuff right now that I'd have to call Tapestry 5.
I don't think there's a way to remove inheritance in the Tapestry 4
code base without distorting many interfaces and breaking backwards
compatibility.
My current vision is that the 4.1 code base will be about creating new
components, including Ajax integration. Most of the innovation is
present in the 3.0 -> 4.0 transition. Some new development may be to
make certain things easier, such as re-introducing <service> in some
way.
will ASOs also have their tapestry xml, instead of fundling around with
hivemind conf-points?
What about the unit testing tapestry apps for tap 4.1 (or
before/separate ) ?
I'm starting to focus beyond that, on Tapestry 5. I'll be drawing
out the code from Tapestry 4 and providing new code. My vision is:
- Annotations based. JDK 1.5.
- No XML for pages and components. Just HTML and Annotations.
I can't really see the big advantage - maybe its just a personal
flavour, but at the moment I like very much defining my components and
beans in XML, parameters and properties in java/annotations - this keeps
my class clean and I know where to find what -
At the moment, the component annotations are not really something I
would like to use, just like the bean ones, when setting a bunch of
properties to the bean.
Its a kind of separation between declatations/functionality (parameters,
properties) and actions (constructing a component).
Also I like to define which components/pages I have instead of letting
tapestry discover them - its a king of control I like to have...
- Concrete, not abstract, page and component classes
- No inheritance imposition
- Transforming class loader driven by annotations (i.e., @Persist on
the field, not the method)
- Change detection; automatic invalidate and reload of changed objects
(including Java classes)
- "Modern" templates: Templates as wellformed XML, using a namespace
for Tapestry attributes and elements
- A "preview" mode for pages
- Partial rendering of pages (for Ajax operations)
- Improved management of page state (including dynamic state during the render)
- Vastly simplified API
- Clear deliniation between public/stable and private/internal/unstable APIs
On 1/31/06, Geoff Longman <[EMAIL PROTECTED]> wrote:
This is OT from the original topic but that topic has spurred a
thought so while it's in my mind I'll regurgitate....
One thing I'm not happy with is that users are forced to use HM in
certain places. For example engine services. Deprecation of <service>
was a bad thing.
Why couldn't there be a convention (default contribution) that melds
services into the engine defined by <service> into HM without actually
needing to write HM xml? Move the complexity out of the user's hands
and into the framework. I've written dozens of Tapestry 3 services
without the *need* to inject anything (other than a few Spring beans
that is).
If a user needs to inject, they use HM. I wonder (and I have not
written a Tap 4 service yet) if people are injecting many of the same
things into their services all the time? Or, why not make the services
abstract like components and inject via annotation?
Hell, if <service> could be resurrected and make people's lives easier
why not user the peer idea Howard is talking about to make Tapestry 3
services work in Tap4+ without modification? This is a pipe dream
really, the interface has changed. There are ways to evolve interfaces
(Eclipse has this down pat) but at this point it's a matter of closing
the barn door after all the horses have bolted.
I guess this boils down to a desire to keep the HM in the framework by
having conventions. The easiest choice is the right choice. When a
user needs to, they can use HM directly. A goal could be that 80% of
end user need to use HM directly 20% of the time.
My 2 cents
Geoff
On 1/31/06, Geoff Longman <[EMAIL PROTECTED]> wrote:
Well, HM has contribution points already and they mirror Eclipse
extension points/extensions to a degree.
There's no reason why Shell couldn't use a contribution point to
discover things like stylesheets to include.
The trick would be to choose an implementation that is intuitive and
easy to use.
Define the mechanism end users would use to indicate something should
be contributed to the shell. Preferably in a way that does not require
the user to add thier own contribution in HM. Then create a default
contribution that knows how to handle that mechanism. I don't know
that that mechanism is as I'm not clear on what you are trying to
achieve. its a topic for discussion
Convention over Customization (as the rails people would say).
That way you have an easy way and the hard way. The easy way is to use
the convention (default contribution). The hard way is to invent your
own custom handler and wire it into the HM contribution point. Good
for weird custom cases.
That way everybody's happy.
Make sense?
Geoff
On 1/30/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote:
hey geoff (or anyone else),
Do you think any of the rcp extension sort of designs might apply to
portions of tapestry? A friend of mine has mentioned it twice to me and
today it started to click a little bit more. (Especially with my recent
discoveries of the Delegate parameter in Shell and others) .
jesse
--
The Spindle guy. http://spindle.sf.net
Get help with Spindle:
http://lists.sourceforge.net/mailman/listinfo/spindle-user
Blog: http://jroller.com/page/glongman
Feature Updates: http://spindle.sf.net/updates
--
The Spindle guy. http://spindle.sf.net
Get help with Spindle:
http://lists.sourceforge.net/mailman/listinfo/spindle-user
Blog: http://jroller.com/page/glongman
Feature Updates: http://spindle.sf.net/updates
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
