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