I have gone through model classes and they mostly make sense. Creating a data flow diagram and sequence diagram for these models will be a good starting point. That will help us to identify if we need any other model class.
Another minor suggestion i have is if we can identify common fields like owner, id in models to a abstract model. Thanks Raminder On Apr 6, 2011, at 6:52 PM, Franklin, Matthew B. wrote: > When looking at OSEC, I would start with the object model > (http://svn.apache.org/repos/asf/incubator/rave/donations/mitre-osec/src/org/mitre/portal/model/). > The Page is the top level object and represents the layout of gadgets that > the user sees. > > -Matt > > > > -----Original Message----- > From: Marlon Pierce [mailto:[email protected]] > Sent: Wednesday, April 06, 2011 12:53 PM Eastern Standard Time > To: [email protected] > Subject: Re: Bootstrapping RAVE code > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Sounds good to me. What is the next step? Can you send pointers to the OSEC > code that illustrate your current approach? > > > Marlon > > > >>> In terms of infrastructure drivers, I think this is probably one of the >>> places to start. There are a lot of implicit features included in this >>> item some (not by any means all) of which are: >> >>> * The pages themselves >>> * Types of Pages >>> * Persistance >>> * Layouts >>> * Page Rendering >>> * Core javascript >>> * The widgets & container support >>> * Shindig authorization >>> * Backend data synchronization with Shindig >>> * Security >>> * Inline vs iFrame widgets >>> * Container API implementation >> >>> So out of this, I suggest the first feature we implement is the basic >>> display of a page and discuss what the infrastructure required to do that >>> is. Specifically, a light-weight object model, rendering engine, page >>> types etc. >> >> >> >> Marlon >> >> >> On 4/5/11 11:19 AM, Franklin, Matthew B. wrote: >>>>> Thanks Marlon. I was planning on kicking up the discussion today also >>>>> :) >>>>> >>>>> Personally, I don't think that starting with a throwaway is quite the >>>>> right route. I agree that we are stalled on the next steps, and that it >>>>> always helps to have code to comment on; but, we already have 2 (soon 3) >>>>> codebases that we can use as drivers for our discussion. >>>>> >>>>> In my mind, the big question is what does the "10,000m" architecture >>>>> (sorry to use a cliché) look like. Not specifics as to how each >>>>> detailed >>>>> component will work, but what are the general organization principles we >>>>> need to follow. For instance, you mentioned creating a skeleton that >>>>> includes Shindig. In our experience, the more loosely coupled the >>>>> application is to Shindig the better. These discussions are more about >>>>> ensuring consistency and providing developers some heuristic to follow >>>>> as >>>>> we break out and implement individual features. >>>>> >>>>> I definitely don't mean to imply that we need to architect or design the >>>>> whole thing up front. That is an equally bad, if not worse, approach >>>>> than >>>>> throw away in my opinion. >>>>> >>>>> That being said, when it comes to putting together the project skeleton, >>>>> Tony, Jesse or I would be more than happy to take a first run. >>>>> >>>>> So back to where do we start? I think the first thing we do is take the >>>>> feature list from the wiki and discuss how we want to implement the >>>>> highest priority one, using the existing codebases as reference for the >>>>> discussion. >>>>> >>>>> -Matt >>>>> >>>>> On 4/5/11 10:47 AM, "Marlon Pierce" <[email protected]> wrote: >>>>> >>>>> Based on previous emails, I think we had consensus on the following >>>>> points: we will start a new code base, and we'll base it on SpringMVC >>>>> framework. Unfortunately that's as far as we've gotten. >>>>> >>>>> I'd like to suggest the following: let's create a skeleton project with >>>>> Spring + Shindig and start fleshing it out. This will be a throw-away >>>>> so >>>>> we will want to tag it appropriately. This should hopefully initiate >>>>> more detailed design discussions over email, etc. I think this will be >>>>> easier if we have some code to comment on. I realize that there is the >>>>> danger that the "throw away" version doesn't actually get thrown away, >>>>> but I think we can accept this risk. >>>>> >>>>> Raminder, Gerald, and I are Spring novices, so we need a volunteer from >>>>> Mitre or Surfnet to design the skeleton. I promise we'll add to the >>>>> framework as soon as it is created. >>>>> >>>>> >>>>> What does everyone think? I'm open to other plans and just want to see >>>>> things start moving. >>>>> >>>>> >>>>> >>>>> Marlon >>>>> > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.16 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJNnJpWAAoJEEfVXEODPFIDvrEH+gOHMoxm7aBszTRwKOD16YtO > ssAMPGvb8OVFk33/mqJmUq1+6i3pi8koFrL93hbnEiwdx9ZnO3o/6+1lY0Ak0uFZ > +Pz5b7RGz2NMCgwxDGQ0jPHXXq1ehAJAyphWrIh7bkwOwuIR7fVygnQyw1JYrGb1 > hiZ+H6xray3XHysWV61VXCjKNLMY0bpA/YzA0JM7gWSPv30xUPAVw66XkmTQGcf0 > 4kuPsV2ieLwhe7JR7Bhddox8Pvw1eQqgXP3i5AlUi/YMUchb3NCi+2am8sMFPjR7 > zs3cMLfYLjYcnPPIjmMz/ljywNnGPbfA4gkDHPzECUPGWGJcFZ8EXLdQw8zywac= > =SN1E > -----END PGP SIGNATURE-----
