[jira] Commented: (SLING-110) Update Script System to be JSR-223 Compatible
[ https://issues.apache.org/jira/browse/SLING-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548160 ] Felix Meschberger commented on SLING-110: - > I think in my last patch I missed updating the DefaultSlingScriptResolver > class No problem. If we have the microsling resolver, we can always derive the other one. > Update Script System to be JSR-223 Compatible > -- > > Key: SLING-110 > URL: https://issues.apache.org/jira/browse/SLING-110 > Project: Sling > Issue Type: Improvement > Components: microsling, Scripting >Affects Versions: 2.0.0 >Reporter: Padraic Hannon > Attachments: bsf.patch, SLING-110_api.patch > > > Currently sling and microsling use a custom scripting framework. This > framework should be updated to be jsr-223 compatible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Suggest removing the /sling/scripts prefix from script names, and adding catch-all default scripts
Hi Bertrand, Am Montag, den 03.12.2007, 16:57 +0100 schrieb Bertrand Delacretaz: > Currently microsling looks for scripts under /sling/scripts, which is > not very convenient if running several apps in the same repository: > all scripts would end up under this path, which makes it harder to > package applications. Very true. The same holds for Sling for the moment. > Here's a proposal for a different way of resolving scripts, with three > possible cases: > > a) Node has a valid sling:resourceType property > The resource type is the value of this property, which, to be valid, > must not be empty and must start with a /. I think, we should allow for relative paths, so no leading slash requirement. But: If there is a leading slash, the resourceType path would be taken as absolute. Sounds reasonable. But, I would say, that for maximum interoperability, such paths should be relative. > b) Node doesn't have a valid sling:resourceType property > In this case, the resource type is the node type, for example > "nt:unstructured". > > To map to a script, the resource type is converted to a valid path, > and prefixed with "/apps/sling". Why not just /apps ? > For an nt:unstructured node, microsling looks for scripts named > /apps/sling/nt/unstructured/. > > c) Script not found using either a) or b) rules > As a catch-all default (useful mostly for tutorials and simple example > apps), microsling looks for scripts named > /apps/sling/default/. I do not like this catch all script. We have the default servlet to catch all. If we have the catch all script, the default servlet will probably never be called :-) As a closing statement: I think it is important to clearly define concerns. The first concern is "every resource has a resource type", the second one is "the script path is derived from the resource type". What is really important to me, is that the resource type is resolved before the script is being resolved. The ScriptResolver only cares for the Resoure.getResourceType. So the first question is: How is the resource type defined ? I think it is (a) the string value of the resource type property. This may be an absolute or relative path or a namespaced name (e.g. nt:file, just like a node type). (b) if there is no resource type property, the primary node type name is used as the resource type. The second question is: How to get the path from the resource type ? I think it is the possibly modified resource type. If the resource type is a namespaced name (that is contains one colon and no slash, such as nt:file but not pref:name/other:name), the colon is replaced by a slash. Otherwise the resource type is taken as a path as is. Finally, the script is looked up below the resource type path if that path is absolute. If the resoure type path is relative a search path (compare to PATH environment variable) is applied. For microsling, this may be fixed, for Sling this will be configurable. WDYT ? Regards Felix
[jira] Commented: (SLING-110) Update Script System to be JSR-223 Compatible
[ https://issues.apache.org/jira/browse/SLING-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548029 ] Padraic Hannon commented on SLING-110: -- I think in my last patch I missed updating the DefaultSlingScriptResolver class from the core package. I will hold off on submitting a patch for that until we work through the above. > Update Script System to be JSR-223 Compatible > -- > > Key: SLING-110 > URL: https://issues.apache.org/jira/browse/SLING-110 > Project: Sling > Issue Type: Improvement > Components: microsling, Scripting >Affects Versions: 2.0.0 >Reporter: Padraic Hannon > Attachments: bsf.patch, SLING-110_api.patch > > > Currently sling and microsling use a custom scripting framework. This > framework should be updated to be jsr-223 compatible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SLING-110) Update Script System to be JSR-223 Compatible
[ https://issues.apache.org/jira/browse/SLING-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548023 ] hannonpi edited comment on SLING-110 at 12/3/07 2:38 PM: --- A few questions/comments: * Drop dependency on BSF in the API ** Does this mean that you want to remove the ScriptEngineManager instance from the ScriptResolver classes? * Rename ScriptBindings to SlingBindings and extend HashMap instead of implementing Java Scripting Bindings. ** I do not understand why we do not want have the binding class implement the scripting bindings interface? * Remove getReader method from SlingScript interface, as it is not externally used ** Makes sense was (Author: hannonpi): A few questions: 1) Why not have bindings implement the scripting bindings interface? 2) > Update Script System to be JSR-223 Compatible > -- > > Key: SLING-110 > URL: https://issues.apache.org/jira/browse/SLING-110 > Project: Sling > Issue Type: Improvement > Components: microsling, Scripting >Affects Versions: 2.0.0 >Reporter: Padraic Hannon > Attachments: bsf.patch, SLING-110_api.patch > > > Currently sling and microsling use a custom scripting framework. This > framework should be updated to be jsr-223 compatible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SLING-110) Update Script System to be JSR-223 Compatible
[ https://issues.apache.org/jira/browse/SLING-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548023 ] hannonpi edited comment on SLING-110 at 12/3/07 2:36 PM: --- A few questions: 1) Why not have bindings implement the scripting bindings interface? 2) was (Author: hannonpi): Looks good, can we get the patch applied? Or does it need more work? Are there other sling apis that need updating for this change? > Update Script System to be JSR-223 Compatible > -- > > Key: SLING-110 > URL: https://issues.apache.org/jira/browse/SLING-110 > Project: Sling > Issue Type: Improvement > Components: microsling, Scripting >Affects Versions: 2.0.0 >Reporter: Padraic Hannon > Attachments: bsf.patch, SLING-110_api.patch > > > Currently sling and microsling use a custom scripting framework. This > framework should be updated to be jsr-223 compatible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-110) Update Script System to be JSR-223 Compatible
[ https://issues.apache.org/jira/browse/SLING-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548023 ] Padraic Hannon commented on SLING-110: -- Looks good, can we get the patch applied? Or does it need more work? Are there other sling apis that need updating for this change? > Update Script System to be JSR-223 Compatible > -- > > Key: SLING-110 > URL: https://issues.apache.org/jira/browse/SLING-110 > Project: Sling > Issue Type: Improvement > Components: microsling, Scripting >Affects Versions: 2.0.0 >Reporter: Padraic Hannon > Attachments: bsf.patch, SLING-110_api.patch > > > Currently sling and microsling use a custom scripting framework. This > framework should be updated to be jsr-223 compatible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Suggest removing the /sling/scripts prefix from script names, and adding catch-all default scripts
Hi, Currently microsling looks for scripts under /sling/scripts, which is not very convenient if running several apps in the same repository: all scripts would end up under this path, which makes it harder to package applications. Here's a proposal for a different way of resolving scripts, with three possible cases: a) Node has a valid sling:resourceType property The resource type is the value of this property, which, to be valid, must not be empty and must start with a /. The resource type is used as the base path under which to look for scripts. For example, if sling:resourceType = /apps/blog/comment, microsling looks for scripts named /apps/blog/comment/., where is the HTTP method (or the extension for the GET method, as done now) and is a valid script extension according to the available ScriptEngines. b) Node doesn't have a valid sling:resourceType property In this case, the resource type is the node type, for example "nt:unstructured". To map to a script, the resource type is converted to a valid path, and prefixed with "/apps/sling". For an nt:unstructured node, microsling looks for scripts named /apps/sling/nt/unstructured/. c) Script not found using either a) or b) rules As a catch-all default (useful mostly for tutorials and simple example apps), microsling looks for scripts named /apps/sling/default/. WDYT? -Bertrand
[jira] Closed: (SLING-98) Adapt Sling projects to new Sling API
[ https://issues.apache.org/jira/browse/SLING-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed SLING-98. -- Resolution: Fixed I think the migration tasks have been done by now. So I close this issue for now. > Adapt Sling projects to new Sling API > - > > Key: SLING-98 > URL: https://issues.apache.org/jira/browse/SLING-98 > Project: Sling > Issue Type: Improvement > Components: Content, Core, Event, JSP, Launcher, Repository, > Scheduler, Scripting >Reporter: Felix Meschberger >Assignee: Felix Meschberger >Priority: Blocker > Fix For: 2.0.0 > > > After the successfull vote for the Sling API [1], the projects have to be > migrated now. > Status of this migration is tracked by SVN commit messages bearing the issue > number of this issue as well as in the respective tracking fields of the > module reorganization wiki page [2]. > [1] http://markmail.org/message/vfqtlnhy4yggv6sc > [2] http://cwiki.apache.org/confluence/x/6REB -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-109) Replace Resource.getRawData and .getObject methods by better API
[
https://issues.apache.org/jira/browse/SLING-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger closed SLING-109.
---
Resolution: Fixed
Adapted now microsling and Sling to the new adapter model, which seems to be
accepted.
Therefore closing this issue.
> Replace Resource.getRawData and .getObject methods by better API
>
>
> Key: SLING-109
> URL: https://issues.apache.org/jira/browse/SLING-109
> Project: Sling
> Issue Type: Improvement
> Components: API
>Reporter: Felix Meschberger
>Assignee: Felix Meschberger
> Fix For: 2.0.0
>
>
> David brought up an issue on the dev list [1] regarding the
> Resource.getRawData() method. In short, David suggests to replace the
> getRawData method with a signature, which more closely reflects the
> definition of Sling as a web application framework for JCR. The general
> consesus on the list is that the getRawData() method is badly named and that
> we should have a method which shows the JCR integration yet does not tie the
> API too much into JCR.
> So I propose the following:
> > Remove the getRawData() and getObject() methods from the Resource
> interface
> > Add new interfaces NodeResource and ObjectResource:
> // resources backed by JCR nodes
> public interface NodeResource extends Resource {
> Node getNode();
> }
> // resources mapped using JCR OCM for example
> public interface ObjectResource extends Resource {
> Object getObject();
> }
> This way, we have the Resource interfaces completely storage-agnostic and
> provide for a wide range of extensions, such as an URLResource, which may be
> backed by a URL such as an entry in an OSGi bundle.
> [1] http://www.mail-archive.com/sling-dev@incubator.apache.org/msg00906.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-114) ECT - Ecmascript Client Templates
[
https://issues.apache.org/jira/browse/SLING-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547833
]
Bertrand Delacretaz commented on SLING-114:
---
Previous commit was broken, revision 600516 works.
> ECT - Ecmascript Client Templates
> -
>
> Key: SLING-114
> URL: https://issues.apache.org/jira/browse/SLING-114
> Project: Sling
> Issue Type: Improvement
> Components: microsling
>Reporter: Bertrand Delacretaz
> Attachments: SLING-114.patch, SLING-114.patch
>
>
> To complete the javascript scripting features for microsling, I'd like to
> implement a client-side version of the ESP templates.
> A template such as
> <%= item.text %>
> Will be processed server-side to generate javascript client code such as
> document.write("");
> document.write(item.text);
> document.write("\n");
> which executes on the client to render the content.
> Combined with a richer XHTML default rendering of data than what we have now,
> this creates interesting possibilities for ajaxish apps based on
> microsling/microjax (SLING-92).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (SLING-114) ECT - Ecmascript Client Templates
On Nov 29, 2007 2:45 PM, Michael Marth <[EMAIL PROTECTED]> wrote: > ...2. Having the same templating language on client and server is nice, but > maybe different delimiters would be a good idea. If the same ones are used > we cannot combine server-side and client-side parts in one script > ...btw: reminded me of the TrimPath stuff now at > http://code.google.com/p/trimpath/wiki/JavaScriptTemplates... That library might be the best choice for people who want to combine client-side with server-side templating: use microsling-provided stuff server-side, and use JavaScriptTemplates (or any other library) client-side. In this way we don't have to reimplement that, and people are free to combine. The aim of SLING-114 (just committed a first version, revision 600516) is a bit different, as it provides in one HTTP request a default HTML rendering (for search engines), a javascript variable intialized via our JSON rendering, and a conversion of the ECT template into client-side rendering code. This is experimental, feedback is welcome of course. -Bertrand
[jira] Commented: (SLING-114) ECT - Ecmascript Client Templates
[
https://issues.apache.org/jira/browse/SLING-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547828
]
Bertrand Delacretaz commented on SLING-114:
---
I haved committed the patch of this morning in revision 600511.
The EctScriptEngine is currently under the
"org.apache.sling.microsling.experimental" package to indicate its experimental
status - this allows people to play with it and comment on its usefulness.
> ECT - Ecmascript Client Templates
> -
>
> Key: SLING-114
> URL: https://issues.apache.org/jira/browse/SLING-114
> Project: Sling
> Issue Type: Improvement
> Components: microsling
>Reporter: Bertrand Delacretaz
> Attachments: SLING-114.patch, SLING-114.patch
>
>
> To complete the javascript scripting features for microsling, I'd like to
> implement a client-side version of the ESP templates.
> A template such as
> <%= item.text %>
> Will be processed server-side to generate javascript client code such as
> document.write("");
> document.write(item.text);
> document.write("\n");
> which executes on the client to render the content.
> Combined with a richer XHTML default rendering of data than what we have now,
> this creates interesting possibilities for ajaxish apps based on
> microsling/microjax (SLING-92).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-109) Replace Resource.getRawData and .getObject methods by better API
[
https://issues.apache.org/jira/browse/SLING-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547813
]
Felix Meschberger commented on SLING-109:
-
Modified the Sling API project as well as the scripting/javascript and the
microsling project.
> Replace Resource.getRawData and .getObject methods by better API
>
>
> Key: SLING-109
> URL: https://issues.apache.org/jira/browse/SLING-109
> Project: Sling
> Issue Type: Improvement
> Components: API
>Reporter: Felix Meschberger
>Assignee: Felix Meschberger
> Fix For: 2.0.0
>
>
> David brought up an issue on the dev list [1] regarding the
> Resource.getRawData() method. In short, David suggests to replace the
> getRawData method with a signature, which more closely reflects the
> definition of Sling as a web application framework for JCR. The general
> consesus on the list is that the getRawData() method is badly named and that
> we should have a method which shows the JCR integration yet does not tie the
> API too much into JCR.
> So I propose the following:
> > Remove the getRawData() and getObject() methods from the Resource
> interface
> > Add new interfaces NodeResource and ObjectResource:
> // resources backed by JCR nodes
> public interface NodeResource extends Resource {
> Node getNode();
> }
> // resources mapped using JCR OCM for example
> public interface ObjectResource extends Resource {
> Object getObject();
> }
> This way, we have the Resource interfaces completely storage-agnostic and
> provide for a wide range of extensions, such as an URLResource, which may be
> backed by a URL such as an entry in an OSGi bundle.
> [1] http://www.mail-archive.com/sling-dev@incubator.apache.org/msg00906.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-109) Replace Resource.getRawData and .getObject methods by better API
[
https://issues.apache.org/jira/browse/SLING-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547792
]
Felix Meschberger commented on SLING-109:
-
After some more discussion on the list (see link in the initial comment)
highlighting sortcomings this interface extension model such as missing
extensibility and keeping a single point reference to the JCR API in the new
NodeProvider interface, we seem to settle on a further possibility: Define a
new adapter method in the Resource interface:
AdapterType adaptTo(Class adapterType);
This method returns the resource adapted to another type. This allows the
implementation to dynamically support adapters upon support. For example the
microsling JcrNodeResource might implement the method as follows (simplified,
ignoring exceptions) :
AdapterType adaptTo(Class adapterType) {
if (adapterType == Node.class) {
return (AdapterType) node;
} else if (adapterType == InputStream.class) {
return (AdapterType) getInputStream();
}
return null;
}
The Sling JcrNodeResoure supporting URLs and object mapping might be :
AdapterType adaptTo(Class adapterType) {
if (adapterType == Node.class) {
return (AdapterType) node;
} else if (adapterType == InputStream.class) {
return (AdapterType) getInputStream();
} else if (adapterType == URL.class) {
return (AdapterType) getURL();
} else if (adapterType == Object.class ||
adapterType.isInstance(getObject())) {
return (AdapterType) getObject();
}
return null;
}
> Replace Resource.getRawData and .getObject methods by better API
>
>
> Key: SLING-109
> URL: https://issues.apache.org/jira/browse/SLING-109
> Project: Sling
> Issue Type: Improvement
> Components: API
>Reporter: Felix Meschberger
>Assignee: Felix Meschberger
> Fix For: 2.0.0
>
>
> David brought up an issue on the dev list [1] regarding the
> Resource.getRawData() method. In short, David suggests to replace the
> getRawData method with a signature, which more closely reflects the
> definition of Sling as a web application framework for JCR. The general
> consesus on the list is that the getRawData() method is badly named and that
> we should have a method which shows the JCR integration yet does not tie the
> API too much into JCR.
> So I propose the following:
> > Remove the getRawData() and getObject() methods from the Resource
> interface
> > Add new interfaces NodeResource and ObjectResource:
> // resources backed by JCR nodes
> public interface NodeResource extends Resource {
> Node getNode();
> }
> // resources mapped using JCR OCM for example
> public interface ObjectResource extends Resource {
> Object getObject();
> }
> This way, we have the Resource interfaces completely storage-agnostic and
> provide for a wide range of extensions, such as an URLResource, which may be
> backed by a URL such as an entry in an OSGi bundle.
> [1] http://www.mail-archive.com/sling-dev@incubator.apache.org/msg00906.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-114) ECT - Ecmascript Client Templates
[
https://issues.apache.org/jira/browse/SLING-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bertrand Delacretaz updated SLING-114:
--
Attachment: SLING-114.patch
Slightly improved patch, default rendering is turned off automatically if
javascript is present, and onLoad() function is called by body.onLoad if
present in template.
> ECT - Ecmascript Client Templates
> -
>
> Key: SLING-114
> URL: https://issues.apache.org/jira/browse/SLING-114
> Project: Sling
> Issue Type: Improvement
> Components: microsling
>Reporter: Bertrand Delacretaz
> Attachments: SLING-114.patch, SLING-114.patch
>
>
> To complete the javascript scripting features for microsling, I'd like to
> implement a client-side version of the ESP templates.
> A template such as
> <%= item.text %>
> Will be processed server-side to generate javascript client code such as
> document.write("");
> document.write(item.text);
> document.write("\n");
> which executes on the client to render the content.
> Combined with a richer XHTML default rendering of data than what we have now,
> this creates interesting possibilities for ajaxish apps based on
> microsling/microjax (SLING-92).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-114) ECT - Ecmascript Client Templates
[
https://issues.apache.org/jira/browse/SLING-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547788
]
Bertrand Delacretaz commented on SLING-114:
---
Here's a simple example template that works with the revised patch that I just
uploaded:
currentNode.title = <%= currentNode.title %>
currentNode.text = <%= currentNode.text %> (changed)
<%
// if present, this function is called by body.onLoad
function onLoad() {
document.title = currentNode.title;
}
%>
> ECT - Ecmascript Client Templates
> -
>
> Key: SLING-114
> URL: https://issues.apache.org/jira/browse/SLING-114
> Project: Sling
> Issue Type: Improvement
> Components: microsling
>Reporter: Bertrand Delacretaz
> Attachments: SLING-114.patch, SLING-114.patch
>
>
> To complete the javascript scripting features for microsling, I'd like to
> implement a client-side version of the ESP templates.
> A template such as
> <%= item.text %>
> Will be processed server-side to generate javascript client code such as
> document.write("");
> document.write(item.text);
> document.write("\n");
> which executes on the client to render the content.
> Combined with a richer XHTML default rendering of data than what we have now,
> this creates interesting possibilities for ajaxish apps based on
> microsling/microjax (SLING-92).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
