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
