I'm fine with any renaming. I also agree with moving struts into it's own package. I've thought about doing this same thing myself on other projects.
Matt On 5/15/06, Allen Gilliland <[EMAIL PROTECTED]> wrote:
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 >
