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.
So perhaps:
org.apache.roller.authoring
Or:
org.apache.roller.editor
org.apache.roller.admin
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 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
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.
- 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
