I haven't used OpenJPA, but would be willing to for a reference persistence implementation.
When we were laying out the feature list, we all agreed that we need to build an object model that supports flexible persistence mechanisms and allow Rave users to inject their own implementations over ours, if they so choose. To that end, I would rather try to identify a less circular model than OSEC. I also think we can probably identify other simplification areas. Much of the model of OSEC ties back to a container object, which was in support of running multiple distinct containers within the same application. A container in this sense is a distinct entry point (think more along the lines of multi-tenant), providing logical separation of all data. I am not sure whether this is a pattern we would like to continue in Rave, but am open to all discussions. -Matt On 4/7/11 10:14 AM, "Raminderjeet Singh" <[email protected]> wrote: >I suggested DFD's for everyone to understand the current models and find >a gap if any or someone need it in different way. Models can be changed >quickly to fulfill requirements . I also believe in looking into the >code. As soon as we decide on build system and Mitre move the Models, I >can help with writing the unit tests for models. > >Another question i have is to use OpenJPA or Hibernate JPA adaptors to >connect to backend. I am using Hibernate adaptor and its working well but >i remember we discussing license problems with that in Apache. > >Thanks >Raminder > >On Apr 7, 2011, at 8:03 AM, Franklin, Matthew B. wrote: > >> >> >> On 4/7/11 4:34 AM, "Ate Douma" <[email protected]> wrote: >> >>> On 04/07/2011 12:52 AM, 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/sr >>>>c/ >>>> org/mitre/portal/model/). The Page is the top level object and >>>> represents the layout of gadgets that the user sees. >>>> >>> Sounds good to me. Starting with the core (basic) Object model just >>>make >>> sense. >>> >>> A remark upfront concerning Page being the top level (layout) object: >>>I'm >>> fine >>> we start out with a simple layout model first. >>> However in my experience with portal layout in general we'll probably >>> need a >>> more fine-grained nested/fragment based layout model later on to >>>support >>> "groups" or "sets" of layout elements which can be pulled in or >>>included >>> within >>> a higher fragment level. The new OpenSocial 2.0 proposal for Spaces >>>also >>> already >>> hints at this. >> >> In OSEC a Page has a list of regions that contain the gadgets, with each >> region containing a set of gadget mappings. It is a little more >>fragmented >> than just a Page with gadgets. >> >>> >>> At Apache Jetspeed we've been using hierarchical fragment based layout >>> (PSML, >>> Portal Structured Markup Language) for years, with the root fragment >>> representing a Page. We even had to add nested fragment references, >>> includes and >>> fragment inheritance models to support all the layout requirements we >>> faced for >>> customers. >>> I'm certainly not suggesting we should use the PSML model for Rave but >>>it >>> might >>> be good not to "tie" layout elements and configuration too strongly to >>> only a >>> single Page concept. >> >> To be clear, I am very open to a different object model or way of >> representing the layouts of Widgets in pages. I am highly in favor of >> simple, flexible models. >> >>> >>> Ate >>> >>>> -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----- >>> >>> >> >
