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 <aa...@apache.org> on 2006/06/02 04:12:57 UTC
Re: Confluence for SoC
[forwarding our conversation with Marcel about the best use cases for
Remote Object Persistence to the list]
On Jun 1, 2006, at 8:28 PM, Marcel wrote:
> I could probably write a Confluence plugin that makes a refreshPage
> method available via XML-RPC or SOAP which would do the job, but we
> are straying into 'when all you have is a hammer, every problem
> looks like a nail' territory...Confluence has a fairly full-
> featured RPC interface available which would be the logical choice
> for implementing an editor like this. We are proposing workarounds
> for what is really a very good system because our solution doesn't
> match the target. I understand why - the aim of the project is to
> get a good example app for Cayenne's ROP - but if we pursue this
> path we are going to end up with something rather awkward which
> won't make the feature look very attractive at all.
>
> My preference would be to move to a target which is better suited
> to the tool at hand. Cayenne provides for direct DB interaction,
> making 'loosely wrapped' applications (in the sense that one can
> operate on the DB without having to crowbar in under the
> application) a much more suitable target. Anything which is written
> in an interpreted Web language - such as PHP or ASP - will be
> amenable to editing via Cayenne ROP because all the data is stored
> in the DB. Confluence seemed, prima facie, like a good target, but
> it has (IMHO) turned out to be too sophisticated. Cayenne deals
> with databases, not applications. I am not fussed what the target
> is, but given that we have a hammer, it should be a nail. I can
> think of a couple of targets off the top of my head - Joomla! open
> source CMS, phpBB bulletin board - but I think it would be a good
> idea to ask the dev list, or even the user list.
All real life systems are sophisticated, I don't see this particular
problem by itself as too bad to turn us away from the Confluence
implementation. However I agree with the bigger point - if we are
building something intended to be used as an example, we'd rather
choose a good one. I am not psyched about an interface to a PHP CMS
either - I am still to find a PHP user who'd agree to run Tomcat on
their server.
From my experience most systems that are using solutions similar to
ROP (and early ROP adopters) are either client programs automating
some business tasks, or applications that need to manipulate visual
data in a way a web browser can't (think Java2D, picture management,
maps, games and such).
The simplest thing would be to do a fake app from the first category.
The cool thing would be to do something from the second or a mix as
it would demonstrate why a Java client is preferred to the web UI.
Just recently I did a prototype for a client using Piccolo
visualization framework [1]. It allows you to display object graphs,
do zooming and panning and moving things around. So we can do a
simple photo album application for instance.
Let's brainstorm other ideas as well, but we need to do it quickly as
the project time is limited.
[1] http://www.cs.umd.edu/hcil/jazz/index.shtml
[2] http://www.cs.umd.edu/hcil/jazz/applications/
index.shtml#java_piccolo
Andrus
Re: Confluence for SoC
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Jun 5, 2006, at 4:08 PM, Marcel wrote:
> I envisage the application working upon a Cayenne Modeler XML file.
> This will load the queries and the objects involved. When a query
> is selected it will be run to get back the initial objects. The
> whole graph will be shown in the application, but the instance data
> won't be loaded for any particular object until it is selected. The
> records returned from the query should be able to be scrolled
> through, and the data edited and saved back to the DB. Is that what
> you had in mind?
I am confused about showing the "whole graph" part. Showing *all*
object graph means showing the entire database. This is certainly NOT
how you want to do it. So let me reiterate: You'd start with a list
of objects fetched for a given query (i.e. a small subset of a db),
and then expand the graph on demand as the user clicks on a
relationships of a specific objects. Cayenne yields itself extremely
well to this type of navigation, lazily resolving relationships
behind the scenes (so instead of "instance data won't be loaded" you
may say "relationship data won't be loaded").
E.g. in response to a query a user may get a list of artists (a1,
a2, ... an). (S)he clicks on some artist's "paintings" relationships,
this would expand a list of paintings for this artist only, and so on.
For version 1.1, we may also take query "prefetching" into account to
show more than one kind of objects on the initial graph.
> Can you point me in the right direction for Cayenne's XML file
> parsing code please? Does Cayenne maintain an accessible (to the
> ROP client) model of the object graph, or will I have to build one
> based upon the XML file?
Cayenne provides all the metadata to you, on the client as well as on
the server. And you don't need to parse any XML.
ObjectContext.getEntityResolver() is what you are looking for.
> The third is to build it under a graphical editor framework such as
> Eclipse's GEF [3]. I am tending towards the latter - it builds in
> editing and visualisation, and I am a fan of Eclipse. There's good
> documentation and good examples - some of which look promisingly
> like what I had in mind for the final application [4]. Moreover it
> can be deployed as a plugin or standalone via RCP.
Sure. GEF/EMF looks ok (and seems to even work on Mac), although I
don't know any of the internals of course.
BTW, looks like a substantial part of the project will be graph
layout - something that can be rather non-trivial [1]. I wonder if
Eclipse tools include auto-layout algorithms (Sugiyama, etc.)? If
this part becomes a problem, you can prototype the whole system using
the UI similar to Apple Finder [2] (or Eclipse class browser), that
should simplify the coding.
[1] http://csbi.sourceforge.net/images/gal.jpg
[2] http://dev.objectstyle.org/~andrus/browser-ui.jpg
Andrus
Re: Confluence for SoC
Posted by Marcel <em...@gmail.com>.
I agree. Next round of questions, to establish a basic plan for this so
that I can get going again (for a bit longer this time I hope!). End of
all this list traffic I hope.
I envisage the application working upon a Cayenne Modeler XML file. This
will load the queries and the objects involved. When a query is selected
it will be run to get back the initial objects.The whole graph will be
shown in the application, but the instance data won't be loaded for any
particular object until it is selected. The records returned from the
query should be able to be scrolled through, and the data edited and
saved back to the DB. Is that what you had in mind? Can you point me in
the right direction for Cayenne's XML file parsing code please? Does
Cayenne maintain an accessible (to the ROP client) model of the object
graph, or will I have to build one based upon the XML file?
In terms of implementation, I see three possible paths. The first is to
custom draw the whole thing. The second is to use a graph visualisation
toolkit such as Piccolo [1] or JGraph [2]. The third is to build it
under a graphical editor framework such as Eclipse's GEF [3]. I am
tending towards the latter - it builds in editing and visualisation, and
I am a fan of Eclipse. There's good documentation and good examples -
some of which look promisingly like what I had in mind for the final
application [4]. Moreover it can be deployed as a plugin or standalone
via RCP.
Ready to roll again!
Marcel
[1] http://www.cs.umd.edu/hcil/jazz/
[2] www.jgraph.com
[3] http://www.eclipse.org/gef/
[4] see http://www.eclipse.org/articles/Article-GEF-EMF/gef-emf.html,
eDiagram example screenshot under 'GEF 3.1 EDiagram Example'
Andrus Adamchik wrote:
>
> On Jun 5, 2006, at 10:24 AM, Marcel wrote:
>
>> Nothing on the Atlassian forums in response to my question. Which way
>> has the hammer fallen on this? The last reply seems to be tending
>> towards a framework for displaying objects visually - I am happy with
>> either.
>
> Hi Marcel,
>
> Yes I was leaning more in favor of an object graph visual management
> application. I am not going to overstep my boundaries as a mentor and
> make decisions for you, but from our discussion it looks like this
> would be the application that makes sense.
>
> BTW, I am glad that we had this discussion. ROP approach, while based
> on commonly used technologies, is certainly not mainstream. It was
> pioneered by Apple/NeXT WebObjects, and AFAIK Cayenne is the only open
> source framework that supports this data management technique. So we
> don't have a large enough pool of empirical data on the practical use
> and have to make some assumptions.
>
> Andrus
>
>
Re: Confluence for SoC
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Jun 5, 2006, at 10:24 AM, Marcel wrote:
> Nothing on the Atlassian forums in response to my question. Which
> way has the hammer fallen on this? The last reply seems to be
> tending towards a framework for displaying objects visually - I am
> happy with either.
Hi Marcel,
Yes I was leaning more in favor of an object graph visual management
application. I am not going to overstep my boundaries as a mentor and
make decisions for you, but from our discussion it looks like this
would be the application that makes sense.
BTW, I am glad that we had this discussion. ROP approach, while based
on commonly used technologies, is certainly not mainstream. It was
pioneered by Apple/NeXT WebObjects, and AFAIK Cayenne is the only
open source framework that supports this data management technique.
So we don't have a large enough pool of empirical data on the
practical use and have to make some assumptions.
Andrus
Re: Confluence for SoC
Posted by Marcel <em...@gmail.com>.
Nothing on the Atlassian forums in response to my question. Which way
has the hammer fallen on this? The last reply seems to be tending
towards a framework for displaying objects visually - I am happy with
either.
Andrus Adamchik wrote:
>
> On Jun 2, 2006, at 11:12 AM, Marcel wrote:
>
>> Your original criticism still remains unresolved: I don't see why
>> would a developer ever bother deploying a web service in these
>> circumstances. The only distinctly ROP element here is the XMPP
>> notification, and that is only relevant where the tool is going to be
>> employed multi-user, and the same mechanism could be achieved in
>> other ways. Don't get me wrong, I like the idea, but as you asked
>> above: what makes it cayenne-rop rather than cayenne?
>
> Because this is not intended for the developers - this is a framework
> for end users. Essentially we'll be building an example that somebody
> can take and convert into a business-specific application with the
> object graph that makes sense in a specific domain. See my comment
> below on general 2-tier vs. 3-tier considerations.
>
>
>> Here's the picture I've been left with of where ROP would actually be
>> employed in the Real World (TM). A servlet-powered web application
>> needs a more powerful tool for some aspects of its operation - most
>> likely administration or visualisation (say via Web Start). If you
>> aren't dealing with a web application in the first place, there is no
>> reason to use cayenne-rop over cayenne.
>
> Not true - cayenne-rop can coexist in an otherwise web app
> environment, but other web applications presence is not relevant at
> all. (e.g. imagine a multiplayer Java game written in Swing - central
> server can be based on rop, and there are no web applications
> involved). I think of it as "webapp plus" and a competitor to Ajax.
>
> On the other hand the aspects that make ROP choice win over two tier
> (client-to-db) approach are:
>
> * Security. I wouldn't claim that the webservice is inherently more
> secure than a DB, but ROP moves security controls to the server
> application tier, allowing things like single sign-on, custom access
> control logic, etc.
>
> * Placing business logic in a server application tier. E.g. you can
> transform the objects on the server, or offload some expensive
> processing from the client. Like you mentioned XMPP integration gives
> collaboration capabilities (and presence information).
>
> In other words ideally you'd have the combined benefits of both worlds
> - webapps and rich desktop apps - something Ajax is trying to achieve,
> only with real desktop UI.
>
> Soon I am going offline till late Saturday. Let's see if there is an
> easy fix to the Confluence update problem, and postpone a decision
> until then. I am actually in favor of the graph browser, as IMO it
> better demonstrates what ROP is, but I am also concerned about timing
> and the learning curve.
>
> Andrus
>
Re: Confluence for SoC
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Jun 2, 2006, at 11:12 AM, Marcel wrote:
> Your original criticism still remains unresolved: I don't see why
> would a developer ever bother deploying a web service in these
> circumstances. The only distinctly ROP element here is the XMPP
> notification, and that is only relevant where the tool is going to
> be employed multi-user, and the same mechanism could be achieved in
> other ways. Don't get me wrong, I like the idea, but as you asked
> above: what makes it cayenne-rop rather than cayenne?
Because this is not intended for the developers - this is a framework
for end users. Essentially we'll be building an example that somebody
can take and convert into a business-specific application with the
object graph that makes sense in a specific domain. See my comment
below on general 2-tier vs. 3-tier considerations.
> Here's the picture I've been left with of where ROP would actually
> be employed in the Real World (TM). A servlet-powered web
> application needs a more powerful tool for some aspects of its
> operation - most likely administration or visualisation (say via
> Web Start). If you aren't dealing with a web application in the
> first place, there is no reason to use cayenne-rop over cayenne.
Not true - cayenne-rop can coexist in an otherwise web app
environment, but other web applications presence is not relevant at
all. (e.g. imagine a multiplayer Java game written in Swing - central
server can be based on rop, and there are no web applications
involved). I think of it as "webapp plus" and a competitor to Ajax.
On the other hand the aspects that make ROP choice win over two tier
(client-to-db) approach are:
* Security. I wouldn't claim that the webservice is inherently more
secure than a DB, but ROP moves security controls to the server
application tier, allowing things like single sign-on, custom access
control logic, etc.
* Placing business logic in a server application tier. E.g. you can
transform the objects on the server, or offload some expensive
processing from the client. Like you mentioned XMPP integration gives
collaboration capabilities (and presence information).
In other words ideally you'd have the combined benefits of both
worlds - webapps and rich desktop apps - something Ajax is trying to
achieve, only with real desktop UI.
Soon I am going offline till late Saturday. Let's see if there is an
easy fix to the Confluence update problem, and postpone a decision
until then. I am actually in favor of the graph browser, as IMO it
better demonstrates what ROP is, but I am also concerned about timing
and the learning curve.
Andrus
Re: Confluence for SoC
Posted by Marcel <em...@gmail.com>.
>> Another possibility is to provide a powerful viewing perspective on a
>> web app such as Confluence - for example, a navigator that can
>> provide a view(s) of the wiki unachievable via the Web. What those
>> views might be is an open question, but one idea is Craig's node
>> navigator, similar to the CNET news map ('The Big Picture') [1].
>> Editing could be introduced using Confluence's RPC interface (the
>> nice way to edit pages ;) ), but that could take a little bit of time
>> (ie I'm not sure how that will go with the Aug 21 deadline - not
>> saying it can't be done, just that there is doubt). Alternatively it
>> could load editing pages in a browser (internal or external). That
>> would emphasise the other advantage of ROP, as a way to supplement a
>> Web interface.
>
> Doing updates via Confluence kind of goes against the goal of
> demonstrating Cayenne graph management capabilities.
>
True. We could allow separate view annotations to be made in tables of
our own? A kind of behind-the-scenes annotation.
>
>> How about a program which displays a graph of the objects that
>> Cayenne has mapped, and browsing and editing of values? I guess that
>> could be done with regular Cayenne, but given that Cayenne's ROP is
>> easy to deploy (just add an ant task to build the classes into a WAR
>> and then deploy it to Tomcat) it might be a useful tool for
>> developers using Cayenne in web applications. After mapping the
>> database, a Cayenne developer would then be able to browse the
>> objects and their contents, and edit the database at an object level.
>> It seems achievable, unless I'm missing a major complexity issue, and
>> it is Cayenne focused. It would seem to be a useful tool on its own,
>> and at some point it could be incorporated into CM if it moved to
>> RCP. ROP functionality could be switched on and off without
>> difficulty, it is simply a matter of getting the context from a
>> different source. To me, that is the greatest advantage of Cayenne
>> ROP - a third tier can be introduced almost completely transparently
>> from the client's perspective. This kind of application would
>> emphasise that.
>
> Correct about ROP transparency to the client app (as long as the code
> is using ObjectContext interface without casting to DataContext or
> CayenneContext). Still I don't see why would a developer ever bother
> deploying a web service in these circumstances. In fact as a developer
> I would rather use the ROP transparency advantage to do the opposite -
> go to the DB directly when developing an ROP app, just to avoid the
> hassle.
Agreed. The only situation of necessity I can think of is where database
access is strictly controlled for one reason or another. For example,
developing on a database behind a firewall or developing on a database
which only accepts localhost connections for security reasons.
>
> Still I like the generic graph viewer/editor idea. With frameworks
> like Piccolo you can really visualize your objects and their
> relationships, providing usability that regular table/form UI can't.
> So maybe we do the same app that you suggested, but "position" it
> differently (I can't believe I am using marketing speak :-)). Not as a
> development tool, but as a framework for building a multi-user visual
> graph manager based on Cayenne model. It can have functionality
> similar to this
>
> Visual Graph Manager:
>
> * A generic GUI application that connects to Cayenne web service
> * A panel to select a mapped named query from the list and run it
> against the server
> * A panel to display a graph of objects that expands when
> relationships are clicked.
> * An ability to select a node on the graph, and edit its properties
> (we can omit relationship editing in version 1.0)
> * An ability to save the whole thing to the server
> * Change notifications - propagate the changes made to objects in one
> client to other clients viewing the same graph (this is the cool thing
> about ROP - it does that for you automatically with XMPP)
> * A sample Cayenne model that demonstrates the above capabilities
>
Your original criticism still remains unresolved: I don't see why would
a developer ever bother deploying a web service in these circumstances.
The only distinctly ROP element here is the XMPP notification, and that
is only relevant where the tool is going to be employed multi-user, and
the same mechanism could be achieved in other ways. Don't get me wrong,
I like the idea, but as you asked above: what makes it cayenne-rop
rather than cayenne?
> However note that Piccolo doesn't work well with SWT (it "kind of
> works"), so the client has to be Swing. IIRC Eclipse has its own graph
> toolkits, although I know nothing about them and won't be able to help
> if there are problems. Are you comfortable doing this with Swing (in
> fact there won't be too much Swing as Piccolo does the rendering)?
I'm not as familiar with Swing as SWT, but as you point out the bulk of
the work would be in Piccolo (which I'm not familiar with either :P).
Not daunted by that however. Terrified would be the word. Fear is a good
motivator.
> General comments?
> Andrus
Here's the picture I've been left with of where ROP would actually be
employed in the Real World (TM). A servlet-powered web application needs
a more powerful tool for some aspects of its operation - most likely
administration or visualisation (say via Web Start). If you aren't
dealing with a web application in the first place, there is no reason to
use cayenne-rop over cayenne.
If it weren't for the way that Confluence works - as a complete system,
wrapping the database rather than separable from it - it would be a
perfect target: administration and visualisation are both relevant.
Given this discussion, I'm almost in favour of going back to Confluence
and writing an RPC plugin to force page refreshes. It isn't nice - I'm
sure the Atlassian folks would be bemused at the avoidance of their
carefully constructed RPC interface - but Confluence provides a much
better target for ROP than I originally appreciated; not ideal (ideal
would be for Confluence to be built as one window on the database, not
_the_ window) but quite good.
First thing I'll do is post to the Atlassian forums and ask if anyone
has any bright ideas in case I've overlooked something regarding
Confluence's refreshes. Then I'll sleep on it. There is time this week
for this discussion to continue (I have to study for an exam over the
weekend), but in a few days a decision will have to be made. If push
comes to shove, Andrus I'll ask you to simply make a decision one way or
the other so that I can get on with it, whatever it may be.
I should say that I appreciate the preparedness to toss ideas around -
both refreshing and empowering.
Regards,
Marcel
Re: Confluence for SoC
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Jun 2, 2006, at 2:15 AM, Marcel wrote:
> Another possibility is to provide a powerful viewing perspective on
> a web app such as Confluence - for example, a navigator that can
> provide a view(s) of the wiki unachievable via the Web. What those
> views might be is an open question, but one idea is Craig's node
> navigator, similar to the CNET news map ('The Big Picture') [1].
> Editing could be introduced using Confluence's RPC interface (the
> nice way to edit pages ;) ), but that could take a little bit of
> time (ie I'm not sure how that will go with the Aug 21 deadline -
> not saying it can't be done, just that there is doubt).
> Alternatively it could load editing pages in a browser (internal or
> external). That would emphasise the other advantage of ROP, as a
> way to supplement a Web interface.
Doing updates via Confluence kind of goes against the goal of
demonstrating Cayenne graph management capabilities.
> How about a program which displays a graph of the objects that
> Cayenne has mapped, and browsing and editing of values? I guess
> that could be done with regular Cayenne, but given that Cayenne's
> ROP is easy to deploy (just add an ant task to build the classes
> into a WAR and then deploy it to Tomcat) it might be a useful tool
> for developers using Cayenne in web applications. After mapping the
> database, a Cayenne developer would then be able to browse the
> objects and their contents, and edit the database at an object
> level. It seems achievable, unless I'm missing a major complexity
> issue, and it is Cayenne focused. It would seem to be a useful tool
> on its own, and at some point it could be incorporated into CM if
> it moved to RCP. ROP functionality could be switched on and off
> without difficulty, it is simply a matter of getting the context
> from a different source. To me, that is the greatest advantage of
> Cayenne ROP - a third tier can be introduced almost completely
> transparently from the client's perspective. This kind of
> application would emphasise that.
Correct about ROP transparency to the client app (as long as the code
is using ObjectContext interface without casting to DataContext or
CayenneContext). Still I don't see why would a developer ever bother
deploying a web service in these circumstances. In fact as a
developer I would rather use the ROP transparency advantage to do the
opposite - go to the DB directly when developing an ROP app, just to
avoid the hassle.
Still I like the generic graph viewer/editor idea. With frameworks
like Piccolo you can really visualize your objects and their
relationships, providing usability that regular table/form UI can't.
So maybe we do the same app that you suggested, but "position" it
differently (I can't believe I am using marketing speak :-)). Not as
a development tool, but as a framework for building a multi-user
visual graph manager based on Cayenne model. It can have
functionality similar to this
Visual Graph Manager:
* A generic GUI application that connects to Cayenne web service
* A panel to select a mapped named query from the list and run it
against the server
* A panel to display a graph of objects that expands when
relationships are clicked.
* An ability to select a node on the graph, and edit its properties
(we can omit relationship editing in version 1.0)
* An ability to save the whole thing to the server
* Change notifications - propagate the changes made to objects in one
client to other clients viewing the same graph (this is the cool
thing about ROP - it does that for you automatically with XMPP)
* A sample Cayenne model that demonstrates the above capabilities
However note that Piccolo doesn't work well with SWT (it "kind of
works"), so the client has to be Swing. IIRC Eclipse has its own
graph toolkits, although I know nothing about them and won't be able
to help if there are problems. Are you comfortable doing this with
Swing (in fact there won't be too much Swing as Piccolo does the
rendering)?
General comments?
Andrus
Re: Confluence for SoC
Posted by Marcel <em...@gmail.com>.
Good point regarding running Tomcat on a PHP server - not a realistic
scenario for most sites.
How about a program which displays a graph of the objects that Cayenne
has mapped, and browsing and editing of values? I guess that could be
done with regular Cayenne, but given that Cayenne's ROP is easy to
deploy (just add an ant task to build the classes into a WAR and then
deploy it to Tomcat) it might be a useful tool for developers using
Cayenne in web applications. After mapping the database, a Cayenne
developer would then be able to browse the objects and their contents,
and edit the database at an object level. It seems achievable, unless
I'm missing a major complexity issue, and it is Cayenne focused. It
would seem to be a useful tool on its own, and at some point it could be
incorporated into CM if it moved to RCP. ROP functionality could be
switched on and off without difficulty, it is simply a matter of getting
the context from a different source. To me, that is the greatest
advantage of Cayenne ROP - a third tier can be introduced almost
completely transparently from the client's perspective. This kind of
application would emphasise that.
Another possibility is to provide a powerful viewing perspective on a
web app such as Confluence - for example, a navigator that can provide a
view(s) of the wiki unachievable via the Web. What those views might be
is an open question, but one idea is Craig's node navigator, similar to
the CNET news map ('The Big Picture') [1]. Editing could be introduced
using Confluence's RPC interface (the nice way to edit pages ;) ), but
that could take a little bit of time (ie I'm not sure how that will go
with the Aug 21 deadline - not saying it can't be done, just that there
is doubt). Alternatively it could load editing pages in a browser
(internal or external). That would emphasise the other advantage of ROP,
as a way to supplement a Web interface.
I am more than happy to implement an application using ROP simply for
example's sake, or to continue and hack around Confluence, but if we can
come up with a 'proper' application of ROP that would be greatly
preferable IMO.
Marcel
[1] eg:
http://news.com.com/Report+Micron%2C+Hynix+e-mails+point+to+price-fix+scheme/2100-1006_3-6078970.html?tag=cd.top
Andrus Adamchik wrote:
> [forwarding our conversation with Marcel about the best use cases for
> Remote Object Persistence to the list]
>
>
> On Jun 1, 2006, at 8:28 PM, Marcel wrote:
>
>> I could probably write a Confluence plugin that makes a refreshPage
>> method available via XML-RPC or SOAP which would do the job, but we
>> are straying into 'when all you have is a hammer, every problem looks
>> like a nail' territory...Confluence has a fairly full-featured RPC
>> interface available which would be the logical choice for
>> implementing an editor like this. We are proposing workarounds for
>> what is really a very good system because our solution doesn't match
>> the target. I understand why - the aim of the project is to get a
>> good example app for Cayenne's ROP - but if we pursue this path we
>> are going to end up with something rather awkward which won't make
>> the feature look very attractive at all.
>>
>> My preference would be to move to a target which is better suited to
>> the tool at hand. Cayenne provides for direct DB interaction, making
>> 'loosely wrapped' applications (in the sense that one can operate on
>> the DB without having to crowbar in under the application) a much
>> more suitable target. Anything which is written in an interpreted Web
>> language - such as PHP or ASP - will be amenable to editing via
>> Cayenne ROP because all the data is stored in the DB. Confluence
>> seemed, prima facie, like a good target, but it has (IMHO) turned out
>> to be too sophisticated. Cayenne deals with databases, not
>> applications. I am not fussed what the target is, but given that we
>> have a hammer, it should be a nail. I can think of a couple of
>> targets off the top of my head - Joomla! open source CMS, phpBB
>> bulletin board - but I think it would be a good idea to ask the dev
>> list, or even the user list.
>
>
> All real life systems are sophisticated, I don't see this particular
> problem by itself as too bad to turn us away from the Confluence
> implementation. However I agree with the bigger point - if we are
> building something intended to be used as an example, we'd rather
> choose a good one. I am not psyched about an interface to a PHP CMS
> either - I am still to find a PHP user who'd agree to run Tomcat on
> their server.
>
> From my experience most systems that are using solutions similar to
> ROP (and early ROP adopters) are either client programs automating
> some business tasks, or applications that need to manipulate visual
> data in a way a web browser can't (think Java2D, picture management,
> maps, games and such).
>
> The simplest thing would be to do a fake app from the first category.
> The cool thing would be to do something from the second or a mix as it
> would demonstrate why a Java client is preferred to the web UI.
>
> Just recently I did a prototype for a client using Piccolo
> visualization framework [1]. It allows you to display object graphs,
> do zooming and panning and moving things around. So we can do a simple
> photo album application for instance.
>
> Let's brainstorm other ideas as well, but we need to do it quickly as
> the project time is limited.
>
>
> [1] http://www.cs.umd.edu/hcil/jazz/index.shtml
> [2] http://www.cs.umd.edu/hcil/jazz/applications/index.shtml#java_piccolo
>
> Andrus
>
>
Re: Confluence for SoC
Posted by Craig Turner <cr...@synect.com>.
Craig Turner wrote:
> - Simple FX pricing system that streams rates for several currency pairs
> to the user and gives them the opportunity to place a spot trade for any
> of the pairs. A priority here would be low delivery time between
I should have said - FX is short for foreign exchange.
--
Craig Turner - craig@synect.com
Synect Online Solutions - http://www.synect.com
Re: Confluence for SoC
Posted by Craig Turner <cr...@synect.com>.
I keep falling into the idea that ROP is a way of exposing cayenne API
as a web service, and that's why I sent a list of wannabe
webapp-applets-that-talk-to-a-database (something that would be dodgy
anyway because you'd lose the ability to maintain data integrity - the
client might have a valid username and pw but give bad orders due to
obscelescence or hacking). Sorry for making a dev list post in spite of
noting reservations about my knowledge of that area.
Andrus Adamchik wrote:
> I don't understand how any of this is related to the project at hand -
> a demonstration of Cayenne Remote Object Persistence (aka Cayenne 3-
> tier) capabilities? I.e. the assumption is that there is a relational
> database on the server accessed by a client via a Cayenne web service.
>
> Andrus
>
>
> On Jun 1, 2006, at 11:46 PM, Craig Turner wrote:
>
>>
>> Andrus Adamchik wrote:
>>
>>> Another possible system can be a multi-user calendar app with Swing
>>> or SWT interface where people can create schedule items and browse
>>> other's schedules. Again, not that there are no calendar apps out
>>> there, but this is a prime example of an ROP use.
>>
>>
>> I've got a list of cool things I'd like to have time to write so I
>> could plug them into webapps:
>> - Simple FX pricing system that streams rates for several currency
>> pairs to the user and gives them the opportunity to place a spot
>> trade for any of the pairs. A priority here would be low delivery
>> time between aquiring the rate and delivering it to the user, and at
>> the other end taking the user's purchase request at the rate they
>> hit. There'd also be an opportunity to see trade history for the
>> team. Opportunity to use Swing or SWT but the interface wouldn't be
>> that complex.
>> - Simple, hardy XML document editor. There is a predefined list of
>> styles, and each block of text can have one and only one style. It
>> would be useful to have this so as to plug it into webapps where
>> there is a publishing emphasis. Would require dev of simple widgets,
>> this may be too complex. Someone with experience developing widgets
>> could show off.
>> - A tree browser, styled as a whiteboard. At any time there's a node
>> in focus, and then that's surrounded by child nodes. Clicking on a
>> child puts it in focus. The rich-client version of this could be far
>> cooler than a non-ajax web version because you could do zooming and
>> pre-caching and stuff, and it would be far easier to create an
>> elegant layout mechanism.
>> - Simple tune player. Idea came when I was trying to describe a tune
>> to a friend over irc and had no means of expression. App has multiple
>> 'lines' of midi data and actually plays it on the client. User can
>> edit each line in a text field using a simple system much like the
>> that used for ringtones on mobile phones. Small amount of Swing/SWT
>> required. Audio aspect might be complex - I'm not sure.
>>
>> I haven't kept up with the list a lot recently - hope these examples
>> are in-spirit.
>>
>>
>> --
>> Craig Turner - craig@synect.com
>> Synect Online Solutions - http://www.synect.com
>>
>
--
Craig Turner - craig@synect.com
Synect Online Solutions - http://www.synect.com
Re: Confluence for SoC
Posted by Andrus Adamchik <an...@objectstyle.org>.
I don't understand how any of this is related to the project at hand
- a demonstration of Cayenne Remote Object Persistence (aka Cayenne 3-
tier) capabilities? I.e. the assumption is that there is a relational
database on the server accessed by a client via a Cayenne web service.
Andrus
On Jun 1, 2006, at 11:46 PM, Craig Turner wrote:
>
> Andrus Adamchik wrote:
>> Another possible system can be a multi-user calendar app with
>> Swing or SWT interface where people can create schedule items and
>> browse other's schedules. Again, not that there are no calendar
>> apps out there, but this is a prime example of an ROP use.
>
> I've got a list of cool things I'd like to have time to write so I
> could plug them into webapps:
> - Simple FX pricing system that streams rates for several currency
> pairs to the user and gives them the opportunity to place a spot
> trade for any of the pairs. A priority here would be low delivery
> time between aquiring the rate and delivering it to the user, and
> at the other end taking the user's purchase request at the rate
> they hit. There'd also be an opportunity to see trade history for
> the team. Opportunity to use Swing or SWT but the interface
> wouldn't be that complex.
> - Simple, hardy XML document editor. There is a predefined list of
> styles, and each block of text can have one and only one style. It
> would be useful to have this so as to plug it into webapps where
> there is a publishing emphasis. Would require dev of simple
> widgets, this may be too complex. Someone with experience
> developing widgets could show off.
> - A tree browser, styled as a whiteboard. At any time there's a
> node in focus, and then that's surrounded by child nodes. Clicking
> on a child puts it in focus. The rich-client version of this could
> be far cooler than a non-ajax web version because you could do
> zooming and pre-caching and stuff, and it would be far easier to
> create an elegant layout mechanism.
> - Simple tune player. Idea came when I was trying to describe a
> tune to a friend over irc and had no means of expression. App has
> multiple 'lines' of midi data and actually plays it on the client.
> User can edit each line in a text field using a simple system much
> like the that used for ringtones on mobile phones. Small amount of
> Swing/SWT required. Audio aspect might be complex - I'm not sure.
>
> I haven't kept up with the list a lot recently - hope these
> examples are in-spirit.
>
>
> --
> Craig Turner - craig@synect.com
> Synect Online Solutions - http://www.synect.com
>
Re: Confluence for SoC
Posted by Craig Turner <cr...@synect.com>.
Andrus Adamchik wrote:
> Another possible system can be a multi-user calendar app with Swing or
> SWT interface where people can create schedule items and browse other's
> schedules. Again, not that there are no calendar apps out there, but
> this is a prime example of an ROP use.
I've got a list of cool things I'd like to have time to write so I could
plug them into webapps:
- Simple FX pricing system that streams rates for several currency pairs
to the user and gives them the opportunity to place a spot trade for any
of the pairs. A priority here would be low delivery time between
aquiring the rate and delivering it to the user, and at the other end
taking the user's purchase request at the rate they hit. There'd also be
an opportunity to see trade history for the team. Opportunity to use
Swing or SWT but the interface wouldn't be that complex.
- Simple, hardy XML document editor. There is a predefined list of
styles, and each block of text can have one and only one style. It would
be useful to have this so as to plug it into webapps where there is a
publishing emphasis. Would require dev of simple widgets, this may be
too complex. Someone with experience developing widgets could show off.
- A tree browser, styled as a whiteboard. At any time there's a node in
focus, and then that's surrounded by child nodes. Clicking on a child
puts it in focus. The rich-client version of this could be far cooler
than a non-ajax web version because you could do zooming and pre-caching
and stuff, and it would be far easier to create an elegant layout mechanism.
- Simple tune player. Idea came when I was trying to describe a tune to
a friend over irc and had no means of expression. App has multiple
'lines' of midi data and actually plays it on the client. User can edit
each line in a text field using a simple system much like the that used
for ringtones on mobile phones. Small amount of Swing/SWT required.
Audio aspect might be complex - I'm not sure.
I haven't kept up with the list a lot recently - hope these examples are
in-spirit.
--
Craig Turner - craig@synect.com
Synect Online Solutions - http://www.synect.com
Re: Confluence for SoC
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Jun 1, 2006, at 10:12 PM, Andrus Adamchik wrote:
> Just recently I did a prototype for a client using Piccolo
> visualization framework [1]. It allows you to display object
> graphs, do zooming and panning and moving things around. So we can
> do a simple photo album application for instance.
>
> Let's brainstorm other ideas as well, but we need to do it quickly
> as the project time is limited.
Another possible system can be a multi-user calendar app with Swing
or SWT interface where people can create schedule items and browse
other's schedules. Again, not that there are no calendar apps out
there, but this is a prime example of an ROP use.
Andrus