Hi all
I am still working on a Spring demo but I'm having a hard time keeping
up with the changes in the trunk. I'm currently trying to make a
configuration for JPA but with the pace of changes, it's really uneasy
to have something workable and that runs correctly.
As I don't have all the time I want to keep up with the changes, would
it be OK if I produce my version of the trunk as a zip file for you to
look at, even if it's not exactly functional and/or working? At least
you will get an idea of the intentions behind it.
The thing is, if Roller decides to go Spring (or even Guice I suppose),
this would probably impact refactoring being done since such changes
will require a little redesign of some pieces (it can go from nothing
major, to big overall - it all depends how much effort can be done and
the level of code quality that is required). You may want to think about
DI and all that while refactoring.
Please let me know
Cheers
Denis Balazuc
Allen Gilliland wrote:
Sure. Since it sounds like people are in favor of this I'll begin
working on it today and I should be able to start committing the changes
this afternoon.
-- Allen
Dave wrote:
Please send out a heads-up before you start work on this.
All my workspaces are checked-in now and ready for a refactoring.
I'll probably drop the roller_guice branch and re-create it when you
are done.
- Dave
On 5/29/07, Allen Gilliland <[EMAIL PROTECTED]> wrote:
Since 4.0 is a major release I'd like to suggest some cleanup and
refactoring work which has no real bearing on functionality but I think
provides some nice cleanup to the project and makes the code easier to
understand and read. These don't have to be taken all together, so feel
free to comment on them independently ...
1. Move Roller Weblogger code to new project space in apps/weblogger/*
structured the same way as the Roller Planet project. This provides
better consistency in the build environment.
2. Update Roller Weblogger java packaging from apache.roller.* to
apache.roller.weblogger.*. It always kind of sucks to do major package
renames like this, but I think this is a good thing and this should be
the last time we have to do this for quite a while.
3. Drop "Data" from the end of our pojo names. I still think that this
convention is a waste and just muddies up our pojo names. At one point
I think this convention was meant to identify which pojos were
persistent, but I see no point in doing that because ultimately
persistence is supposed to be transparent. Also, pretty much all our
pojos are persistent anyways so all we've really done is made our pojo
names longer for no reason.
4. Rename some pojos for consistency. One general theme here is to
append "Weblog" in front of those objects which are directly attached to
a weblog to make that relationship clear ...
WebsiteData -> Weblog
PermissionsData -> WeblogPermission
FolderData -> WeblogBookmarkFolder
BookmarkData -> WeblogBookmark
HitCountData -> WeblogHitCount
RefererData -> WeblogReferrer
CommentData -> WeblogEntryComment
EntryAttributeData -> WeblogEntryAttribute
RoleData -> UserRole
I think that's enough for now. Please weigh in with your thoughts on
these, I'd like to start applying them soonish if we are agreed.
-- Allen
