I need a new folder in framework

[Adrian Crum]

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

[Jacques Le Roux]

Seems logical to me. Easier to understand

Jacques

From: "Adrian Crum" <[hidden email]>

> 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
>

[David E Jones]

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

[Adrian Crum]

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
>
>

[David E Jones]

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

[Adrian Crum]

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
>
>

[David E Jones]

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

[Adrian Crum-2]

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

-Adrian


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

> From: David E Jones <[hidden email]>
> Subject: Re: I need a new folder in framework
> To: [hidden email]
> 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

     

[David E Jones]

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 <[hidden email]> wrote:
>
>> From: David E Jones <[hidden email]>
>> Subject: Re: I need a new folder in framework
>> To: [hidden email]
>> 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
>
>
>

[Adrian Crum-2]

Have everything in one folder? Yuck! I wouldn't like that at all.

-Adrian


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

> From: David E Jones <[hidden email]>
> Subject: Re: I need a new folder in framework
> To: [hidden email]
> 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
> <[hidden email]> wrote:
> >
> >> From: David E Jones
> <[hidden email]>
> >> Subject: Re: I need a new folder in framework
> >> To: [hidden email]
> >> 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
> >
> >
> >

     

[Jacques Le Roux]

Who would want that ?

Jacques

From: "Adrian Crum" <[hidden email]>

> Have everything in one folder? Yuck! I wouldn't like that at all.
>
> -Adrian
>
>
> --- On Fri, 10/3/08, David E Jones <[hidden email]> wrote:
>
>> From: David E Jones <[hidden email]>
>> Subject: Re: I need a new folder in framework
>> To: [hidden email]
>> 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
>> <[hidden email]> wrote:
>> >
>> >> From: David E Jones
>> <[hidden email]>
>> >> Subject: Re: I need a new folder in framework
>> >> To: [hidden email]
>> >> 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
>> >
>> >
>> >
>
>
>      
>