You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Andrus Adamchik <an...@objectstyle.org> on 2010/01/05 13:45:24 UTC

Storing JGraphs and the new project model

Looks like we'll need to settle on a more permanent solution for  
storing the graph XML file sooner than I expected. Currently there's  
work being done on switching the Modeler to the new 3.1 project  
structure. This task is a blocker for many other 3.1 improvements, so  
we need to finish the switch ASAP.

The switch will introduce the new configuration model with one  
DataDomain per configuration stack. This means that the current  
mechanism for storing JGraph XML file, as implemented in  
org.apache.cayenne.modeler.ModelerProject will no longer work. We can  
probably make it work with the new API using some other means, but I'd  
rather we have a clear picture first.

I still prefer the solution that I suggested before - store the layout  
files under ~/.cayenne/, using generated unique names tied via  
preferences to the filesystem location of a given project. Later we  
can expand that to allow "Save As / Open" features, etc. to allow  
users more control, but for now this should be the least invasive  
option that would allow us to evolve the graph engine in the  
background without affecting the users' ability to work with Modeler  
3.1.

Thoughts?
Andrus

Re: Storing JGraphs and the new project model

Posted by Malcolm Edgar <ma...@gmail.com>.
+1

I think this sounds like a good approach, as it is a design time artefact.
If people want to check it in they will have to save to their source control
system.

On Tue, Jan 5, 2010 at 11:45 PM, Andrus Adamchik <an...@objectstyle.org>wrote:

> Looks like we'll need to settle on a more permanent solution for storing
> the graph XML file sooner than I expected. Currently there's work being done
> on switching the Modeler to the new 3.1 project structure. This task is a
> blocker for many other 3.1 improvements, so we need to finish the switch
> ASAP.
>
> The switch will introduce the new configuration model with one DataDomain
> per configuration stack. This means that the current mechanism for storing
> JGraph XML file, as implemented in org.apache.cayenne.modeler.ModelerProject
> will no longer work. We can probably make it work with the new API using
> some other means, but I'd rather we have a clear picture first.
>
> I still prefer the solution that I suggested before - store the layout
> files under ~/.cayenne/, using generated unique names tied via preferences
> to the filesystem location of a given project. Later we can expand that to
> allow "Save As / Open" features, etc. to allow users more control, but for
> now this should be the least invasive option that would allow us to evolve
> the graph engine in the background without affecting the users' ability to
> work with Modeler 3.1.
>
> Thoughts?
> Andrus
>

Re: Storing JGraphs and the new project model

Posted by Andrey Razumovsky <ra...@gmail.com>.
Hi Andrus,

Generally I see the trouble of keeping current graph storing engine. But
currently I'm very very busy here, so I'wont be able to accomplish that in
nearest time. So if the issue really blocks you, I suggest complete turning
off graph saving as quick temporary solution (unless someone wishes to take
the work, of course). Anyways, I've no objections to saving graph to other
location

2010/1/5 Andrus Adamchik <an...@objectstyle.org>

> Looks like we'll need to settle on a more permanent solution for storing
> the graph XML file sooner than I expected. Currently there's work being done
> on switching the Modeler to the new 3.1 project structure. This task is a
> blocker for many other 3.1 improvements, so we need to finish the switch
> ASAP.
>
> The switch will introduce the new configuration model with one DataDomain
> per configuration stack. This means that the current mechanism for storing
> JGraph XML file, as implemented in org.apache.cayenne.modeler.ModelerProject
> will no longer work. We can probably make it work with the new API using
> some other means, but I'd rather we have a clear picture first.
>
> I still prefer the solution that I suggested before - store the layout
> files under ~/.cayenne/, using generated unique names tied via preferences
> to the filesystem location of a given project. Later we can expand that to
> allow "Save As / Open" features, etc. to allow users more control, but for
> now this should be the least invasive option that would allow us to evolve
> the graph engine in the background without affecting the users' ability to
> work with Modeler 3.1.
>
> Thoughts?
> Andrus
>



-- 
Andrey