It sounds like you're running into a problem with how you're trying to
organizing this. In general the framework is organized into the higher
level tools like the entity engine, service engine, widgets, webapp
tools, etc. There are many framework features which end up having
touch points in a lot of these higher level tools. The framework is
organized by the higher level tools and not by the individual features
that cut across multiple tools in the framework.
The calendar stuff you are talking about cuts across various higher
level tools in the framework, and those tools represent different
levels in the framework with dependencies between them. If you try to
put it in a single component instead of organizing it the way the rest
of the framework is organized you'll run into circular dependencies.
Not to minimize your work (this is a great set of features for OFBiz
and you're really adding some cool stuff), but in a way this is like
the status management stuff in the OFBiz Framework, though admittedly
a more complex case. It wouldn't make much sense to have the status
stuff in its own component because it is just one of many features
that is used in various parts of the framework, though mostly used in
the applications. It can live in the common component because none of
the lower level components use it. We don't really have that luxury
with time management stuff. It has lower level pieces that will be
used by the framework, and higher level pieces that use high level
parts of the framework for user interaction and such.
In other words, it is a feature with many touch points in the
framework and one would expect to see the code for that one "feature"
spread across various "tool" components.
-David
On Oct 3, 2008, at 12:15 PM, Adrian Crum wrote:
My proposal was to consolidate all calendar-related code into one
folder. In other words, move the recurrence stuff from service into
the new folder.
I picture the entire calendar framework looking something like this:
1. A calendar API - get a calendar, query it, etc.
2. Calendar persistence workers - to/from entity engine, to/from
iCalendar, etc.
3. Calendar UI workers - Java code to provide convenience objects to
UI artifacts
4. Re-usable UI artifacts - ftl files, widgets, etc.
-Adrian
David E Jones wrote:
But still, why have yet another place where calendar related stuff
exists? Why not put it with the other things already there?
-David
On Oct 3, 2008, at 11:48 AM, Adrian Crum wrote:
Have you taken a look at the jetty and geronimo folders? Once the
calendar stuff is completely built out, it will be larger than
those. Its size will probably be more along the lines of the bi
folder.
-Adrian
David E Jones wrote:
Wouldn't it be kind of a small component if we restrict it to
just calendar stuff?
My opinion on this is to just keep it with the other stuff in the
service component, since we already have things there. Hopefully
there has been enough discussion about it and there is enough
precedent with the recurrence entities that people won't have a
hard time with it.
Don't worry too much about it. It is what it is, and it's okay.
-David
On Oct 3, 2008, at 9:21 AM, Adrian Crum wrote:
As was discussed before, I had a hard time deciding where to put
the new temporal expression stuff because of dependencies in the
build process. I ended up putting it in the service component in
order to get everything to compile okay, but seriously, it
doesn't make sense having it there.
I have more calendar-related classes I want to introduce to the
project, and I will end up having the same problem with those. I
don't want to put everything in service. I need a new folder in
the framework folder.
The calendar classes (recurrence and temporal expression) depend
upon the base and entity components. The service component
depends upon the calendar classes (for job scheduling). So, I
need the new folder to be in between entity and service in the
build process.
I'd like to add a calendar folder to the framework folder. It
would contain all of the existing recurrence classes, the
temporal expression classes, and the yet-to-be-committed classes.
I wouldn't suggest this if I could find some other logical way
to place things.
What do you think?
-Adrian
