I don't really know what to answer to this.
Me and John are pretty motivated on this, and the only thing John's
code cannot handle is circular dependencies.
I guess we'll start implementing and using the proposed solution for
the project here. as we don't need a full blown persistence engine.
Sure this will help start a (side?) discussion at the geek meet indeed.
Have a nice week end.
Niko,
On Sep 7, 2006, at 4:13 PM, Philipp Bracher wrote:
On Sep 7, 2006, at 1:34 AM, Nicolas Modrzyk wrote:
A) We store the workitems in the magnolia way (same structure as
paragraphs) this allows to use the dialogs to manipulate them
(currently they are stored unfortunately as plain xml)
Nicolas & John: what do you think about A) should we enforce
that? I think there are other use-cases where we would like to
have that
I don't really remember what the structure for paragraph is, but I
think it would be good to have an API to persist java objects to
the JCR, generically. (hibernate for JCR ?)
I think this should not get done by this project and we are waiting
for something coming up since a long time.
At least there is a helper Util to transform simple beans to nodes
and visa versa. See ContentUtil.setProperties() and setNodeDatas().
But those methods are only used for flat properties and should net
get overloaded in my opinion. But still this can reduce the lines
of code dramatically.
Since we don't need a general full configurable mechanism this can
get done quite easily by using BeanUtils for example. We would need
a general way to handle Collections, Maps and Objects. How every we
were warned several times to start doing this by ourself. But if we
restrict ourself to what is obviously possible and easy done we
could go for it.
Not sure but perhaps an simple solution could relay on xstream.
This project doesn't allow a flexible mapping but saves beans to
xml cleanly. How ever the problems are starting early where we
store multivalues (in paragraphs), we create a subnode and then a
collection of properties (named 0, 01, 02, ..), which is fine for
us, but maybe not for persisting general object structures.
But definitely we must leave the way to use every where Content
objects which is quite inflexible and avoids the usage of dialogs
and similar in a general way.
But this could be one of a side discussion on the geek meet.
We have a couple of examples in magnolia I guess:
- users
- roles
- groups
- workitems
Also in my code here, I also need to persist some searches object
(that I'm doing just the same dirty way; serialize to xml..)
I get the feeling it would not be to hard for us to define a
generic API, and for me and John to implement it.
What do you think ?
Niko,
----------------------------------------------------------------
for list details see
http://www.magnolia.info/en/magnolia/developer.html
----------------------------------------------------------------
----------------------------------------------------------------
for list details see
http://www.magnolia.info/en/magnolia/developer.html
----------------------------------------------------------------
----------------------------------------------------------------
for list details see
http://www.magnolia.info/en/magnolia/developer.html
----------------------------------------------------------------
