David M Johnson wrote:
I was thinking about where to put the new model classes and came to
basically the same conclusion. We need a packag reorg. Here are some
whiteboardy thoughts on that topic.
I like the first two packages you proposed.
org.apache.roller.ui.core
org.apache.roller.ui.rendering
But I don't really like the word "publishing" because it's ambiguous and
doesn't cover all of the things that we do with the editor/admin UI.
Perhaps "authoring" or "editing" or "admin". Or perhaps we should
separate editor and admin into separate packages.
yeah, i think you're right. "publishing" really only represents a
subset of the things you can do via the admin/editor interfaces.
So perhaps:
org.apache.roller.authoring
Or:
org.apache.roller.editor
org.apache.roller.admin
i like "authoring", but like "publishing" it doesn't tell the whole
story, so maybe we do need 2 packages. maybe "authoring" and
"administration"?
org.apache.roller.ui.authoring (weblog authoring tools)
org.apache.roller.ui.administration (global admin/planet tools)
Also, I'd like to separate out our Struts dependencies, because someday
we may be using a different framework (or frameworks).
So perhaps:
org.apache.roller.ui.struts
Or:
org.apache.roller.ui.editor.struts
org.apache.roller.ui.admin.struts
i agree, breaking things down by implementation makes sense. i like the
version with "editor" and "admin" in it, or "authoring" and
"administration".
I guess I like the first one best, because all Struts stuff goes under
one package.
And then, under the Struts package, do we really need to separate
actions into separate packages? Why not just put our 30-40 actions
together into one package where they can be easily found in alphabetical
order. And the same thing for our forms.
org.apache.roller.ui.struts.actions
org.apache.roller.ui.struts.forms
definitely agree.
If we going to do a reorg, we might want to do it before starting work
in the Roller 3.0 branch, otherwise merging will be a less enjoyable
experience.
yeah, that's why i wanted to propose this today and see if we can go
ahead an do this in the trunk now. it would definitely be a major PITA
to do this in the 3.0 branch and then have to merge.
-- Allen
- Dave
On May 15, 2006, at 12:31 PM, Allen Gilliland wrote:
i'd like to make a proposal that we do a quick re-org on the
presentation layer classes to group them into a set of logical
packages based on functionality. these names are just what popped
into my head, so that is totally flexible if anyone things they have
better names for the packages ...
1. in general, rename roller.presentation.* to roller.ui.<component>.*
where we will discuss the components below.
2. the first component will be "core" and will hold any
presentation/ui classes that provide functionality to the entire ui
layer.
roller.ui.core.util.*
roller.ui.core.filters.*
roller.ui.core.tags.*
util is an obvious inclusion. filters is there because some filters
apply to the whole ui layer, like the CharEncodingFilter and
PersistenceSessionFilter. and tags.* is there because we allow some
jsp tags to be used in multiple components.
3. the second component will be "rendering" and will hold any ui
classes that provide functionality for the rendering/displaying of
content.
roller.ui.rendering.filters.*
roller.ui.rendering.newsfeeds.*
roller.ui.rendering.search.*
roller.ui.rendering.servlets.*
roller.ui.rendering.velocity.*
this is basically where our Page, Flavor, Search, etc, servlets will
go, along with caching filters, etc. anything that is purely about
content rendering.
4. the third component will be "publishing" and will hold any ui
classes that provide functionality for the publishing/admin process.
roller.ui.publishing.ajax.*
roller.ui.publishing.bookmarks.*
roller.ui.publishing.pings.*
roller.ui.publishing.planet.*
roller.ui.publishing.weblog.*
roller.ui.publishing.website.*
this is all of our struts UI work that manages the admin and editor
interfaces for content publishing and site administration. i am
actually thinking we could possibly further subdivide this package
between publishing.admin.* and publishing.editor.* if we want.
so that's the jest of if. why do this? just because it's nice to
have a cleanly organized package structure and i think this makes it
easier to separate out the rendering and publishing code.
thoughts? comments?
-- Allen
