On 08/08/2008, at 9:14 PM, Andrey Razumovsky wrote:
Hello,
My activity as a GSoC student comes to its end. Anyways, I'd like to
stay.
The reasons are obvious: I like Cayenne, I wanna become an Apache
committer,
ORM is useful in 90% business applications.
Your work has been very valuable to Cayenne, and very much
appreciated. Although working on the modeler might only seem like
tinkering around the edges of Cayenne, it is very much the first
impression users get of Cayenne and therefore extremely important to
the project.
1. Reverse engeneering.
If there is a pluggable naming engine, it must have a couple of simple
prepackaged options available as choices in Cayenne modeler since few
people will probably go to the trouble of writing their own java
plugin. There could be a series of checkboxes and options in the
modeler to make it even easier. This could be taken a further step to
control the generation of the velocity templates for entity class
generation. For example we've added:
public static Class<?> getDataTypeForKey(String key)...
to ours since we find it quite useful. It would be great to allow
users to easily control the naming and options within the entity
superclass without tinkering with velocity templates which can be a
bit obscure.
2. Core API.
Generified SelectQuery (and related classes) is the thing Cayenne
definitely misses. I think I've seen some discussion about it, so
maybe
someone is currently working on it. This doesn't seem too hard of a
task, we
must just look at correct deprecating of present methods, which take
Class
as parameter (like SelectQuery constructor).
I think you'll find that there are as many opinions on this as
developers :-) but I agree that we should complete the generification
of Cayenne before 3.0 final is released. I think that SelectQuery is
one of the last main bits to do. As Andrus said, DataRows was the main
issue and the conversations (as I recall) revolved around whether you
choose to perform a DataRow query when you construct the query or when
you ask for the results.
4. ROP
I haven't thought of how to implement this yet, but nested contexts
are
needed on client side.
Yes! +1 That would be incredibly useful.
Some thoughts about removing "Client classes have to be available to
the
server JVM" limitation. My colleague once shared experience, that if
client
and server classes are in same package, client classes are not
needed on
server. I.e. client objects are serialized and server objects
are deserialized. If we could somehow tell Hessian that package of
classes
may change, that'd solve a problem.
Putting client and server entities in the same inheritance hierarchy
would simplify lots of things for users. For instance, right now it is
very hard to share validation between client and server classes.
I also have some thoughts about CM usability, but I'm a bit tired of
modeler
now, if you know what I mean :-) Maybe later.
I would appreciate any comments and suggestions.
My main thought there would be to add documentation to the modeler. I
think it would be quite simple and is mostly a UI challenge. Each
relationship, attribute and entity should allow text which then gets
dumped into javadocs in the generated classes and methods. Really,
just a bunch of big text areas in the modeler with a convenient way to
edit them and view them alongside the things they describe. I'm
thinking that maybe a panel across the bottom. Using the docs in
tooltips in the modeler (when you hover over an attribute for
instance) would also be good.
It might be useful to write them out into a separate XML file (not the
main Cayenne model file) so that they don't have to be exposed to the
client in ROP for security reasons. Not sure what others think about
that, since it adds a little complexity.
Anyhow, please don't hesitate to create Jira's for anything you think
of. That will allow everyone to contribute to the ideas. We want to
welcome you to working on Cayenne and encourage any ideas that you
want to develop.
Ari Maniatis
-------------------------->
ish
http://www.ish.com.au
Level 1, 30 Wilson Street Newtown 2042 Australia
phone +61 2 9550 5001 fax +61 2 9550 4001
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
