Re: Multi-pass rendering
Hi Bryce, On Mon, Jul 7, 2008 at 4:44 AM, Bryce Ewing <[EMAIL PROTECTED]> wrote: > ...I am wondering if there is any way to do a two (or more) pass rendering for > content,... I don't think this is currently possible without using workarounds. > ...Multi rendering: > GET /alpha/beta.html > ... (not sure about this part) ... > uses two scripts to render the content, one which takes it from source to > intermediary then a second one to render to html... What could work (as a temporary solution) might be for your script to make another http request that generates the first format, captures that output and provides it to the module (FOP in your example) that generates the second format. But maybe someone has a better idea about how to do pipelines with the current codebase? Note that you could also create a specific servlet for this FOP/PDF case, wire it to .pdf requests and have it use the repository document view XML as input to an xslt transform script, that feeds into FOP (see http://xmlgraphics.apache.org/fop/0.94/embedding.html). >... Maybe something like this would work? > GET /alpha/beta.xml.html > resource /alpha/beta.xml (which has sling:resourceType = "test2") > uses /apps/test2/html.ftl to render the node beta.xml -> beta.xml.html > resource /alpha/beta (which has sling:resourceType = "test1") > uses /apps/test1/html.ftl to render the node beta -> beta.xml... Do you mean encoding in the URL the steps used to generate the response? I don't like that too much. I'd prefer implementing real pipelines, using a specific *script* extension to control a simple pipeline engine: GET /foo/bar.pdf (resource type foo) -> handled by /apps/foo/pdf.pipeline script Where pdf.pipeline might be a simple pipeline control language: transform /apps/foo/xslt/xslfo.xsl serialize org.apache.sling.serializers.fop options outputFormat=pdf Carsten mentioned Commons Sandbox Pipeline as something that might help implementing this, (http://markmail.org/message/2mtvwt4cxfpkgkas), and there's also the experimental Cocoon Corona project, a minimal version of Cocoon that includes pipelines. So currently (and I'd love to be proved wrong on this one) I think you'd have to resort to workarounds to do this (or implement a custom .pdf servlet), and I think we need to introduce simple pipelines for such cases at some points. Contributions are most welcome as usual ;-) -Bertrand > > A specific example of where this would come in handy would be: > /alpha/beta -> /alpha/beta.xml -> /alpha/beta.xml.pdf (where the xml step > is fop) > > Maybe I am going down a completely wrong track with the multi-pass rendering > so more specifically how would I render a pdf (via first creating fop)? > > Cheers > Bryce > -- Bertrand Delacretaz http://www.codeconsult.ch
Re: Image rendering (image creation / manipulation)
On 7 Jul 2008, at 14:48, Bryce Ewing wrote: One of the issues I see with this is that it would require the imageio and jai libraries to be added somewhere that would then be visible to this even though in most cases nobody would use jsp for this etc. Also I don't think this would be that easy for someone who doesn't know a reasonable amount about jai and imageio. Our experience with adding image manipulation capabilities to our product has been that JAI is possible to use, but in practise requires too much memory and / or is too slow for real usage. You be better off writing a wrapper around the "convert" utility of ImageMagick. It would be handy to have an open source utility library that would be easy to "plug into" sling, with different backends for image manipulation implemented either with JAI or wrappers as described. -- Torgeir Veimo [EMAIL PROTECTED]
Image rendering (image creation / manipulation)
Hi, I am thinking of creating a way of doing image rendering through sling and thought I would first check with the community as to whether this has been thought of, and whether there are any thoughts on how this may work. Thoughts that I have had as to what this can be used for are (among others): * scaling * rotation * watermarking * layering (i.e. use one image as background another as foreground) * format changing e.g. png -> jpg * quality change (to reduce size of say jpg) So say /img/test is a png image (with sling:resourceType = "abc/def") and I requested /img/test.jpg that something would reformat the image from png to jpg. If I requested /img/test.small.jpg the image would be reduced and the format changed. So I guess the most "basic" way of doing this would be to write a servlet that specifically did a certain type of image creation / manipulation. But this seems a little tedious to me, and not very customizable by someone in the future. Another thought would be that something like JSP or Groovy would be used to do the image manipulation and there was a script that did this say: /apps/abc/def/jpg.jsp One of the issues I see with this is that it would require the imageio and jai libraries to be added somewhere that would then be visible to this even though in most cases nobody would use jsp for this etc. Also I don't think this would be that easy for someone who doesn't know a reasonable amount about jai and imageio. What I have been thinking about and what I am proposing is another scripting bundle that is specifically used for image creation and manipulation. This would then have some sort of source (still thinking about how this would work) that would define the processing to perform. Initial thoughts are something along the lines of a set of parameterized JAI operators, e.g. SubsampleAverageDescriptor, UnsharpMaskDescriptor, AddDescriptor. Maybe not strictly a script either but a set of nodes in the repository which makes up the "script"? Would be interested in any feedback, other options etc. before I start design / development of this. Cheers Bryce
Multi-pass rendering
Hi, I am wondering if there is any way to do a two (or more) pass rendering for content, i.e. Single rendering: GET /alpha/beta.html resource /alpha/beta (which has sling:resourceType = "test") uses /apps/test/html.ftl to render the node beta -> beta.html Multi rendering: GET /alpha/beta.html ... (not sure about this part) ... uses two scripts to render the content, one which takes it from source to intermediary then a second one to render to html Maybe something like this would work? GET /alpha/beta.xml.html resource /alpha/beta.xml (which has sling:resourceType = "test2") uses /apps/test2/html.ftl to render the node beta.xml -> beta.xml.html resource /alpha/beta (which has sling:resourceType = "test1") uses /apps/test1/html.ftl to render the node beta -> beta.xml A specific example of where this would come in handy would be: /alpha/beta -> /alpha/beta.xml -> /alpha/beta.xml.pdf (where the xml step is fop) Maybe I am going down a completely wrong track with the multi-pass rendering so more specifically how would I render a pdf (via first creating fop)? Cheers Bryce
Re: Resources provided by Restlet
Thanks Felix,
What you have suggested sounds ideal and I think that will do exactly
what I want. I wont be able to do this right at the moment due to
pressing deadlines, but will let you know once I get a chance to come
back to this.
Cheers
Bryce
Felix Meschberger wrote:
Hi Bryce,
Sorry for chiming in late, I was distracted by other work ...
Yes, your problem might well be solved by a combination a
ResourceProvider and a registered Servlet.
The ResourceProvider would make the RESTlet provides resources visible
in Sling's virtual resource tree. So if you map /users to in RESTlet,
your ResourceProvider would provide a Resource backed by Hibernate
representing the collection of users. This collection would have a
specific resource type, say "restlet".
The Servlet you provide is registered for the resource types provided
by the ResourceProvider (use the sling.servlet.resourceTypes service
property) and for "all" methods (set sling.servlet.methods to the
special value "*"). The Servlet's service() method would simply
forward to the RESTlet servlet.
Now all requests to the resources provided by the RESTlet
ResourceProvider having no request extension (e.g. /users or
/users/123) would be handled by your Servlet forwarding to RESTlet.
In addtion - for presentation - you might create servlets or scripts
for the RESTlet resource types for specific extensions. E.g. you
create a script /apps/restlet/html.jsp to handle requests to /users.html
Does this help ?
Regards
Felix
Bryce Ewing schrieb:
Ok, I think I have managed to totally confuse you, so will try to
come up with a concrete example.
Restlet User example:
POST {
firstName: "First",
lastName: "Last",
address: {
line1: "Line 1",
line2: "Line 2",
city: "City", ... etc.
}
}
to /users creates /users/123
This will now return the same json representation when a GET is
performed on the /users/123 uri (PUT against this uri will update the
user, and DELETE will remove them). All of this is being performed
through the restlet part of the system.
Then say across the fence on the portal part of the system (which is
being delivered by sling) we have a uri /addressbook/users/123.html
that will display an html representation of the user along with their
address, and this will be rendered into the portal template etc. by a
script say /apps/addressbook/html.ftl
I think that this part might be able to be accomplished with
ResourceProvider, though slightly confused how this works, but I am
not sure if I would also be able to do a PUT against
/addressbook/users/123 in order to update the user entry or whether I
would have to go straight to the /users/123 uri to do this?
Bertrand Delacretaz wrote:
On Wed, Jul 2, 2008 at 11:41 AM, Bryce Ewing <[EMAIL PROTECTED]> wrote:
...What I have done at present is to move all the restlet based api
under /api
(managed by a restlet servlet). But I would also like to be able
to access
the data from within Sling and use the same rendering methods etc
That's where I'm not sure what you mean, can you give an example of an
URL that would be processed by Sling, and what you expect it to do?
And what would differentiate that URL from one that's processed by
Restlet?
-Bertrand
[jira] Created: (SLING-566) Make JcrPropertyMap public
Make JcrPropertyMap public -- Key: SLING-566 URL: https://issues.apache.org/jira/browse/SLING-566 Project: Sling Issue Type: Wish Components: JCR Resource Affects Versions: JCR Resource 2.0.2 Reporter: Tobias Bocanegra the current JcrPropertyMap in org.apache.sling.jcr.resource.internal.helper.jcr is package protected. although node resources can be adapted to ValueMaps, sometimes when having a node structure it would be very convenient using the JcrPropertyMap directly and not having to re-adapt it via a resource. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-549) Scala interpreter should use the current ClassLoader instead of rebuilding its own classpath
[ https://issues.apache.org/jira/browse/SLING-549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12610818#action_12610818 ] Bertrand Delacretaz commented on SLING-549: --- In the scala eclipse plugin [1], the intializePaths() method sets the classpath for the scala compiler. That plugin looks like a good example of using the compiler, but it also uses a list of strings for the classpath (which makes sense in an IDE context). [1] http://lampsvn.epfl.ch/svn-repos/scala/scala-plugin/trunk/src/scala/tools/eclipse/ScalaPlugin.scala > Scala interpreter should use the current ClassLoader instead of rebuilding > its own classpath > > > Key: SLING-549 > URL: https://issues.apache.org/jira/browse/SLING-549 > Project: Sling > Issue Type: Bug > Components: Scripting >Reporter: Bertrand Delacretaz >Priority: Minor > > As the code at [1] demonstrates, the scala interpreter rebuilds its own > classpath from the current JVM classpath and user-supplied additions. > We should find a way for it to use the current classloader instead. > Note that the almost same test [2] works when run with "mvn test" without > setting the classpath explicitly, probably because in this case the JVM > classpath includes the scala jars. > [1] > http://code.google.com/p/sling-scala/source/browse/trunk/scala-min-bundle/src/main/java/org/apache/sling/scripting/scala/minbundle/ScalaCompileServlet.java > [2] > http://code.google.com/p/sling-scala/source/browse/trunk/scala-min-bundle/src/test/java/org/apache/sling/scripting/scala/minbundle/ScalaCompilerTest.java?r=38 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: o.a.s.jcr.base.internal.loader.Loader vs. o.a.s.jcr.resource.internal.loader.Loader
Am Donnerstag, 17. April 2008 schrieb Felix Meschberger: > Hi Oliver, Hello Felix, thanks for your detailed explanation and sorry for my late reply. I had to move development from a dying Mac OS X 10.4 (ppc/32bit) system to a new 10.5 (intel/64bit) system and cannot reproduce the problem anymore. The CND files (with namespace included) I used for my development are from a working Magnolia-based project. It works fine now, though I have some more questions... > Am Donnerstag, den 17.04.2008, 13:17 +0200 schrieb Oliver Lietz: > > hello all, > > > > why are there two Loaders? I'm asking because initial content (with > > custom node types and namespace) loading from bundle by Loader from > > resource fails due to missing namespace handling. The necessary methods > > are present in Loader from base, wonder why they are not used. > > This is historic. Initially there was just one loader (in the > jcr/resource module) which contained node type registration and initial > content loading. This loader has been split some time ago, such that > node type registration, which is a repository-wide operation, is part of > repository "initialization" in the jcr/base module, and the initial > content loading, which is specific to the Sling workspace, remained in > the jcr/resource module. > > Namespace handling is split: One is the namespaces used for the node > type registration. These namespaces should be listed in the node type > definition file (aka CND-file). The other part is the namespaces > available in the JCR sessions. These namespaces should be declared in a > bundle - mostly the bundle making the initial node type registration - > in the Sling-Namespaces header. See for example the jcr/resource module > [1] itself which defines the sling namespace. > > Now, the namespaces are defined in a JCR session emitted from the > session pool manager by calling the Loader.defineNamespacePrefixes > method on the session to be returned for login. This should actually > work pretty fine. > > Nevertheless, if you encounter issues, you are very welcome to raise a > JIRA so that we can fix this. [...] The ContentLoader from o.a.s.jcr.contentloader doesn't support same name siblings which is a requirement. It's easy to extend the loader but I'm unsure about the impact on the rest of Sling. Looks like most parts of Sling have to be touched to support SNS. Is it worth the effort? Should I stick to Sling or start a new project? thanks, O.
