Dave Johnson wrote:
Comments below...
On 9/14/06, Allen Gilliland <[EMAIL PROTECTED]> wrote:
I think the proposal looks good. Only 2 things I would comment on ...
1. Rather than put this in the sandbox I suggest we go ahead and start
by putting this in a more long term home where we think it should live.
I would vote for the blueprints style of project layout ...
http://java.sun.com/blueprints/code/projectconventions.html
using this layout structure i would suggest that for the Modular Planet
proposal that we start simply by creating an apps/planet directory which
holds build specifics for the planet webapp. eventually we should move
everything there (src, web, etc), but for now if its just a build script
and a few other things then that's fine.
I think that's a good layout and would not be against restructuring the
directories like that, but I have a couple of concerns:
- We want to get a planet app up and running quickly, so is now
the time to restructure directories across the app?
- I'd like to keep things relatively stable so Elias can do his tagging
work in the trunk and perhaps a directory restructuring is too
destabilizing.
I've already started in the sandbox and I'll continue there until we
find the
right home for the code. I can always move later.
I didn't mean that we have to move anything critical yet, just the stuff
that is used in the assembly of the webapp. So basically just an "mv
sandbox/planetroller apps/planet" and that's it. I don't think moving
that stuff would affect anything that other people are working on.
SIDE NOTE: although it wouldn't need to be part of this proposal, i
would also suggest that if we agree to adopt the blueprints layout that
we update other parts of the repository to match for consistency. i.e.
or tools directory -> lib
Yes, but I don't really like lumping all jars into one directory.
I didn't mean that all the jars go in one directory, it just means that
we rename 'tools' to 'lib'. there can still be subdirectories under lib
for various packages.
2. I'm not sure I understand the need for static generation. Can't we
just do a jsp for pages and use the planetrss servlet? It just seems
like creating static generation code would be doing work that we already
expect to change.
I already have a Velocity/Texen static generation system that works well in
(see PlanetTool in the sandbox). So this is not "doing work that we already
expect to change," it's using code that works now so I can focus on other
issues (like the UI, which is not insignificant).
With the static system in PlanetTool, each planet group can define a
control
template that in turn generates HTML, RSS, OPML or whatever else is needed.
By using static generation, we don't need to bring in a page servlet, feed
Servlet or figure out how to do caching. We just let the app server
serve up
the pages.
Eventually (3.2 timeframe?), I'd like to have a full rendering system based
on the interfaces you put together in 3.0 but for now static is the
quickest
path to working app.
that's fine with me. I didn't realize you had the static generation
stuff already done.
It would probably be a good idea to see a small description of the url
layout for the planet app as well.
Assuming the application is hosted at the root URL of a site, you'd have
a set of URLs for the main aggregation:
http://hostname/index.html
http://hostname/index.rss
http://hostname/index.atom
http://hostname/index.opml
And then a set of URLs for each aggregation group defined:
http://hostname/<group-handle>.html
http://hostname/<group-handle>.rss
http://hostname/<group-handle>.atom
http://hostname/<group-handle>.opml
But the exact file generated is determined by the control template.
not that it's a huge deal, but i think it would be slightly better if we
could follow the same convention for groups as for the main aggregation
and then use directories for the group name. i.e.
http://hostname/<group-handle>/index.html
http://hostname/<group-handle>/index.rss
http://hostname/<group-handle>/index.atom
http://hostname/<group-handle>/index.opml
the only reason i think that's a little bit nicer is that assuming that
once we change to dynamic delivery then it's easier to transition to the
same base url structure as Roller with /<group-handle>/* being used for
a given group.
-- Allen
- Dave
