I wish there was a better way to organize things. Unfortunately with so many possible dependencies between things the easiest, and possibly "cleanest" alternative would be to have one big component for the entire framework. While I've thought about it a few times (and would be interested in other's thoughts about it) I've always considered it to be too "messy", ie a potential big/ugly mess of spaghetti code. Of course, maybe that's just my own bias?

-David


On Oct 3, 2008, at 1:50 PM, Adrian Crum wrote:

Okay, I'll just put things where they make the most sense.

-Adrian


--- On Fri, 10/3/08, David E Jones <[EMAIL PROTECTED]> wrote:

From: David E Jones <[EMAIL PROTECTED]>
Subject: Re: I need a new folder in framework
To: [email protected]
Date: Friday, October 3, 2008, 12:43 PM
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




Reply via email to