Is there a plan to support write access

[camunda]

Hey guys!

I had a quick look at the DNA documentation today and saw, that connectors like FileSystem or Sunbversion provide a read-only access. This is pretty limited, since quite often you have to at least to change existing content or even create new content.

Is write-access planed? If yes, is there already a timeframe for it? Or nobody else faces issues in that area?

By the way: Does anybody know a good generic web browser to access a JCR repostory? We would liketo take this as a base to add own gui components, based on the node type of the content.

Thanks a lot and cheers

Bernd

[bcarothers]

I had a quick look at the DNA documentation today and saw, that connectors like FileSystem or Sunbversion provide a read-only access. This is pretty limited, since quite often you have to at least to change existing content or even create new content.

Is write-access planed? If yes, is there already a timeframe for it? Or nobody else faces issues in that area?

That's actually a documentation bug for the file system connector (which we've fixed in trunk, sorry!).  That connector has supported write access since 0.6, although only for nt:folder, nt:file, and nt:resource node types  The idea is that the file system connector provides read-write support for a file system through JCR, not as a file-based store for arbitrary JCR data.

Write support for the SVN connector is in progress, but I can't give you an ETA for it yet.

By the way: Does anybody know a good generic web browser to access a JCR repostory? We would liketo take this as a base to add own gui components, based on the node type of the content.

I tried looking for one of these myself about 8 months ago, but at the time, I couldn't get DNA to load in any of them.  That should work much better now, particularly if you build from the SVN trunk.  Let us know if you run into any problems, please.

[camunda]

Thanks for the quick answer! Okay, got the idea with the file system. At the moment, the SVN would be more important to me ;-) Does "in progress" mean, there is work going on, or there is something started yet or it is planned? Could be, that we jump in with the project if we need it, but not yet sure, maybe we do it besides DNA as well to avoid the overhead (basically we just need a JCR interface to different kinds of resources, not a combines repository view).

For the browser: So you have an idea, which could be maybe leveraged for that?

Thanks

Bernd

[bcarothers]

Does "in progress" mean, there is work going on, or there is something started yet or it is planned?

There's work going on, but the write-access part hasn't been committed to the trunk.

For the browser: So you have an idea, which could be maybe leveraged for that?

I was looking at http://www.jcr-explorer.org/, but I see that it hasn't had a release in quite some time.

[camunda]

There's work going on, but the write-access part hasn't been committed to the trunk.

Anybody I can ping, if would like to start working as well?

I was looking at http://www.jcr-explorer.org/, but I see that it hasn't had a release in quite some time

Okay, funny. This was written by a colleage of me in camunda, but he moved to another country and (even worse) to another world (the microsoft one ;-)). This explains why there weren't any releases yet. Maybe we take it and go on with it, but I wanted to check if there are other possibilities as well...

[bcarothers]

Anybody I can ping, if would like to start working as well?

I've pinged him, but with the holiday it may take a couple of days to get a response.

This explains why there weren't any releases yet.

Yeah, sorry.  I ended up googling around and not finding much on this front.

[bcarothers]

SVN write support is expected in the next week or two.  Optimizing performance will take a bit longer, but it should be usable on local repositories.

[bcarothers]

An SVN connector that supports full write access[1] is now in trunk and will be released as part of 0.7.  Pat Serge Pagop on the back if you run into him ;-)

[1] - Like the file system connector, it only supports nt:folder, nt:file, and dna:resource nodes, not arbitrary primary types

[camunda]

Awesome! Yeah, I will do as soon as I see Serge again...

[kukeltje]

camunda wrote:

I was looking at http://www.jcr-explorer.org/, but I see that it hasn't had a release in quite some time

Okay, funny. This was written by a colleage of me in camunda, but he moved to another country and (even worse) to another world (the microsoft one ;-)). This explains why there weren't any releases yet. Maybe we take it and go on with it, but I wanted to check if there are other possibilities as well...

Any progress on this? I've picked up working on my jBPM 3 JSF console again (also making it work with 4) and want to incorporate things like JCR exploring. Since it is also richfaces based, it would make a great combination. I've checked out the source and will try to make it up to date with the latest richfaces release and maybe even seamenize it.

Cheers,

Ronald

[rhauch]

kukeltje wrote:

camunda wrote:

I was looking at http://www.jcr-explorer.org/, but I see that it hasn't had a release in quite some time

Okay, funny. This was written by a colleage of me in camunda, but he moved to another country and (even worse) to another world (the microsoft one ;-)). This explains why there weren't any releases yet. Maybe we take it and go on with it, but I wanted to check if there are other possibilities as well...

Any progress on this? I've picked up working on my jBPM 3 JSF console again (also making it work with 4) and want to incorporate things like JCR exploring. Since it is also richfaces based, it would make a great combination. I've checked out the source and will try to make it up to date with the latest richfaces release and maybe even seamenize it.

I'd be very interested in hearing how this worked. Apparently, people still use it. Plus, it looks like it works with any JCR Repository loaded into JNDI, which of course ModeShape can do.

[camunda]

We are working on some application in that area as well (okay, my colleage wrote the jcr-explorer first, unfortunately he "converted" to the Microfot-World for the moment ;-)). I will let you know as soon as I can and have something to show... But at the moment it seems, that we build our own app again instead of reusing it, since it is pretty generic on JCR; which we don't need in the current project.

Cheers

Bernd

[rhauch]

camunda wrote:

... since [JCR Explorer] is pretty generic on JCR...

That's something I dislike as well. Personally, I'd find it much more useful to have an app that exposed the views in a way that is much more domain-specific, where one could define additional domain-specific views and store them as content in the repository.  Plus, these views should allow displaying a subgraph, not just a single node.  For example, our DDL sequencer constructs a graph representation of the various DDL statements, and our JDBC Metadata connector exposes the components (or entities or tables, whatever your favorite terminology is) available within a database. Users would feel right at home if they could use a web app that presented these as tables with columns and constraints and indexes, but then other content in its particular domain (e.g., web services, Java modules, etc).

It's up in the air as to how to best determine which view to use for each node, but I suspect it'd work really well to make the decision based upon node types (primary type and mixins), especially if the app could display multiple views if applicable (sort of a faceted approach to viewing the content).

Personally, I dislike Sling's approach to doing this because it requires the client to specify the 'view' (and the representation type!) in the request URL. First, the representation type should be in the HTTP header (standard REST best practice), but the requesting client likely knows little about the content (without extra work or some convention).  IMO the request client should specify the representation format (e.g., HTML, JSON, XML, etc.) via the HTTP header, but the content should dictate the "domain view(s)" used to generate the representation content.

Does this make sense?  Am I off-base?

[bcarothers]

I don't think that's off-base.  I particularly agree with the concept of making view decisions based on node types.

What I have not quite figured out yet is how to store the information that allows the view to be rendered.  I think we had talked about having some kind of meta-language, but that still seems too complex for me.  I think it might be simpler to have a "view" which is a Java class that implements an interface (like a "sequencer" does).

What would be the proposed output technology for this "view"?  Something that just spits out XML would make it hard to updates through the view, unless something funky was added, like a JSF control that spoke our XML dialect.

[kukeltje]

Sorry for the delayed reply... Have been busy with other things.

The jcr-explorer works nicely with the Richfaces components and from my jBPM 3 JSF console (not the one that comes with jBPM 3, but a 'new' seam/richfaces based one) can open attachments to process instances that are stored in modeshape (still have to get used to it). My next step will be to include 'jsf snippets' in the processdefinition that can be used in e.g. taskforms to display metadata in a way you want it to be visible. So the issue of jcr explorer being generic is tackled then (although it is only slightly related to the jcr-explorer at the moment)

Maybe this kind of pluggability can be added to JCR explorer to and e.g. reference a template (in the repository?) that should be used to display specific metadata... which template to use could itself be stored in the metadata again...

Any other thoughts?

Cheers,

Ronald