You've definitely opened what could be a "can o worms", but I'll make my
response brief.
The suggested change in general I like, the more things we can do to make
dropping in libraries easier (ie without extra configuration ) - the better.
The problem, this introduces more "artifact" sort of issues which Geoff has
hinted at very validly. To do it completely properly we should probably
also:
-) Deprecate *.library / *.application altogether. Not remove support mind
you, just deprecate them for removal in a future release. (4.2 ? ) So far
I've seen a lot of good @deprecated java usage, we should probably also
introduce a special logging category of some kind that outputs deprecated
warnings for non java items like these specification files.
It could be a misunderstanding, but I view these files as just another <=
3.X artifact that haven't been updated yet to use the "new" way, which is
via hivemind. This leads us to the next point.
-) Create a full page / section in the 4.x series documentation outlining
the sort of hivemodule essentials that people will need to know to configure
tapestry. This should cover all the logic in .library / .application (moved
into its new hivemodule.xml form) , as well as common tasks like replacing
Exception pages / all of the common ${template} sort of tapestry global
configuration possibilities / core service points like Cookiemanager/
WebRequest / Etc...
People shouldn't have to go to the hivemind site to use tapestry. This is
true. Not even to use the cool hivemind features of tapestry. The removal of
.library/.application combined with a proper page or two of documentation on
the tapestry site might be able to fix this.
-) ~Remove~ old documentation referencing the deprecated way of doing
things...Or, some sort of "deprecated" page that is clearly not part of the
main set of documentation so people aren't confused about how many options
there are...Ie these are clearly the old "bad" way of doing things, use it
this way if you must but ~this~ is the right way to do configuration...
-) Maven2 has already started to solve our documentation problems in
general. It is very very fast and less time consuming to publish these sites
with it now, which should hopefully encourage a more active release cycle
for documentation. It would be nice to see any / all tapestry devs feel free
to make a quick doc fix and immediately publish. It is so lightening fast to
do the actual site build + site deploy (two commands) that I hope this will
be realized..
Ok....So..Great idea, so long as we do something along the lines of
everything listed above :)
On 6/15/06, James Carman <[EMAIL PROTECTED]> wrote:
We should discuss the idea of library auto-discovery here on the dev list.
Obviously, it's needed/wanted. So, let's come up with the best way to do
it
considering Tapestry's current design goals. I would rather see libraries
configured via HiveMind. You can create a new configuration point called
tapestry.Libraries which has a schema equivalent to what the .library
files
currently contain. They could assign themselves a default "namespace"
which
can be overridden by the end user somehow. This way, we don't have to
come
up with a new auto-discovery mechanism (HiveMind has this built in). I
think this more "gels" with the way Tapestry is going (HiveMind
configuration). I know there are opposing views, but I just wanted to get
this discussion started on the appropriate list.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Jesse Kuhnert
Tacos/Tapestry, team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind.
