Brett, Just curious. Have you considered leveraging a portal/portlet framework at all for Continuum's web site? It seems to me that a lot of things around security, report entitlement, plus customizability would be provided out of the box. If you guys are interested, check out the portals project. There may even be people willing to help out including myself.
Regards, David Le Strat. --- Brett Porter <[EMAIL PROTECTED]> wrote: > Hi, > > Ok, here's a summary of what I did with the > continuum model: > - rebuilt the model from scratch based on the web > design. > - implemented it separately and tested it thoroughly > in isolation. > - migrated the app over to the new model, removing > the old one > > Changes in the new model: > - package is o.a.m.c.model.* (added model. to the > package), removed > Continuum from the class names. This is consistent > with m2's use of the > model. > - many-to-many relationship was broken down into > 1-to-many. This was > necessitated by the design, not any technological > limitation. > - added dependant relationships for most > - changed identifiers to integers rather than string > ints, and removed > id fields from those not meant to be looked up on > their own > - constructed fetch groups based on the page flows > - other small things, eg "forced" changed to > "trigger" so we can track > what caused the build (web, soap req, schedule, etc) > > Things still broken: > - I haven't gone back and updated velocity > templates. Doing that now. > - There may be some more bugs in the web stuff that > wasn't covered by > the integration tests. I'm checking it over. > - I haven't done the persistence/testing for the > users/permissions stuff yet > > There are afew areas I'm still not happy with. The > fetch groups don't > seem to fit well with what is required a lot of the > time. I'm wondering > whether we are better off making everything be in > the default fetch > group, and lazy loading the lists instead. It seems > since we are only > doing this as an optimization that'd be a better way > to do it. > > We'd still need to avoid long lists, ie build > results. I think that > should not be a field on the project, and instead it > should just have > references to the last successful build, last > finished build, current > build (either in progress or finished). > > I'm not particularly happy with using store methods > "mid-way" through a > block of code. I'm not sure if it does any dirty > checking when you do a > re-attach,but I see potential to read something, > have it changed > externally, then write over the top of it. The fact > that we are > re-retrieving from the db at random points could > make this harder to > track. I think we should be in the practise of > getting all we need from > the db at the start, modifying the detached objects, > then updating them > with dirty check at the end. We need to be able to > resolve common cases > where we can recover, and fail gracefully when it > can't. At the end of > the day, this isn't preventing it working now, so > I'll just schedule a > review of the use of the store later as it may be a > source of ongoing > bugs otherwise. > > So, where do we go from here? > > I would like to see us knock off all the pages in > the design as soon as > possible. This should be the easy bit as it is all > just forms and > presentation now I believe. Some of the features > aren't supported in the > backend yet (like security, displaying test reports, > generated > artifacts), so they can be omitted for now. Does > everyone agree? > > Cheers, > Brett > > > ________________________ David Le Strat Blogging @ http://dlsthoughts.blogspot.com __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
