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
