Have everything in one folder? Yuck! I wouldn't like that at all. -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: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 > > > > > >
