Nabble - Magnolia - Dev

[JIRA] Commented: (MAGNOLIA-2931) templating: the renderer should not only wrap the content for the template but for the model too

2009-11-08T12:31:36Z

[ http://jira.magnolia-cms.com/browse/MAGNOLIA-2931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=24775#action_24775 ]

Hudson CI server commented on MAGNOLIA-2931:
--------------------------------------------

Integrated in !http://hudson.magnolia-cms.com/nocacheImages/16x16/yellow.gif! [magnolia_main-trunk #1086|http://hudson.magnolia-cms.com/job/magnolia_main-trunk/1086/]
: also wrap the content when passing to the model

> templating: the renderer should not only wrap the content for the template but for the model too
> ------------------------------------------------------------------------------------------------
>
> Key: MAGNOLIA-2931
> URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2931
> Project: Magnolia
> Issue Type: Improvement
> Components: templating
> Reporter: Philipp Bärfuss
> Assignee: Philipp Bärfuss
> Fix For: 4.2
>
>

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.magnolia-cms.com/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
----------------------------------------------------------------

[JIRA] Commented: (MAGNOLIA-2897) Introduce a simpler api to build nodes/properties

2009-11-08T12:31:36Z

[ http://jira.magnolia-cms.com/browse/MAGNOLIA-2897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=24776#action_24776 ]

Hudson CI server commented on MAGNOLIA-2897:
--------------------------------------------

Integrated in !http://hudson.magnolia-cms.com/nocacheImages/16x16/yellow.gif! [magnolia_main-trunk #1086|http://hudson.magnolia-cms.com/job/magnolia_main-trunk/1086/]

> Introduce a simpler api to build nodes/properties
> -------------------------------------------------
>
> Key: MAGNOLIA-2897
> URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2897
> Project: Magnolia
> Issue Type: New Feature
> Components: core
> Reporter: Grégory Joseph
> Assignee: Grégory Joseph
> Fix For: 4.2
>
>
> We've had the need several times for a simple node building api - especially in version handlers - to construct relatively simple nodes (couple of nodes, couple of properties) without having to maintain complex bootstrap or properties file, and verbose/long code.
> We'll introduce a simple DSL/API similar to the one used to build tasks and deltas for this. Hopefully this will be easy-to-use and follow some of the "fluent" principles.
> A starting point was proposed at MAGNOLIA-2828; after some discussion we've adapted it and came up with a slightly different implementation.

Hudson build is unstable: magnolia_main-trunk #1086

2009-11-08T12:30:36Z

See <http://hudson.magnolia-cms.com/job/magnolia_main-trunk/1086/changes>

----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
----------------------------------------------------------------

Hudson build is back to normal: magnolia_main-trunk » magnolia-core #1086

2009-11-08T12:30:34Z

See <http://hudson.magnolia-cms.com/job/magnolia_main-trunk/info.magnolia$magnolia-core/1086/changes>

----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
----------------------------------------------------------------

Hudson build is unstable: magnolia_main-trunk » magnolia-module-templating #1086

2009-11-08T12:30:34Z

See <http://hudson.magnolia-cms.com/job/magnolia_main-trunk/info.magnolia$magnolia-module-templating/1086/changes>

----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
----------------------------------------------------------------

[JIRA] Created: (MAGNOLIA-2931) templating: the renderer should not only wrap the content for the template but for the model too

2009-11-08T12:23:37Z

templating: the renderer should not only wrap the content for the template but for the model too
------------------------------------------------------------------------------------------------

Key: MAGNOLIA-2931
URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2931
Project: Magnolia
Issue Type: Improvement
Components: templating
Reporter: Philipp Bärfuss
Assignee: Philipp Bärfuss
Fix For: 4.2

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.magnolia-cms.com/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
----------------------------------------------------------------

Build failed in Hudson: magnolia_main-trunk #1085

2009-11-08T12:22:09Z

See <http://hudson.magnolia-cms.com/job/magnolia_main-trunk/1085/changes>

Changes:

[pbaerfuss] MAGNOLIA-2897:
- rename
- move
- copy
- onChildNodes
- recursive

------------------------------------------
A SCM change trigger started this job
Updating http://svn.magnolia-cms.com/svn/community/magnolia/trunk
U magnolia-core/src/main/java/info/magnolia/nodebuilder/Ops.java
At revision 29308
Parsing POMs
[trunk] $ java -cp /usr/local/hudson/data/plugins/maven-plugin/WEB-INF/lib/maven-agent-1.324.jar:/usr/local/hudson/maven/apache-maven-2.0.10/boot/classworlds-1.1.jar hudson.maven.agent.Main /usr/local/hudson/maven/apache-maven-2.0.10 /Library/Tomcat/work/Catalina/hudson.magnolia-cms.com/_/WEB-INF/lib/remoting-1.324.jar /usr/local/hudson/data/plugins/maven-plugin/WEB-INF/lib/maven-interceptor-1.324.jar 56028
<===[HUDSON REMOTING CAPACITY]===> channel started
Executing Maven: -B -f <http://hudson.magnolia-cms.com/job/magnolia_main-trunk/ws/trunk/pom.xml> clean install
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO] magnolia-project
[INFO] magnolia-core
[INFO] magnolia-jaas
[INFO] magnolia-gui
[INFO] magnolia-module-exchange-simple
[INFO] magnolia-module-templating
[INFO] magnolia-module-admininterface
[INFO] magnolia-module-mail
[INFO] magnolia-module-workflow
[INFO] magnolia-module-cache
[INFO] CMS Tag Library
[INFO] CMS Utility Tag Library
[INFO] magnolia-module-fckeditor
[INFO] magnolia-module-samples
[INFO] magnolia-empty-webapp
[INFO] ------------------------------------------------------------------------
[INFO] Building magnolia-project
[INFO] task-segment: [clean, install]
[INFO] ------------------------------------------------------------------------
[INFO] [clean:clean]
[INFO] Deleting directory <http://hudson.magnolia-cms.com/job/magnolia_main-trunk/ws/trunk/target>
[TASKS] Skipping non-existent folder '<http://hudson.magnolia-cms.com/job/magnolia_main-trunk/ws/trunk/src/main/java'...>
[TASKS] Skipping non-existent folder '<http://hudson.magnolia-cms.com/job/magnolia_main-trunk/ws/trunk/src/main/resources'...>
[TASKS] Skipping non-existent folder '<http://hudson.magnolia-cms.com/job/magnolia_main-trunk/ws/trunk/src/main/resources'...>
[TASKS] File encoding has not been set in pom.xml, using platform encoding MacRoman, i.e. build is platform dependent (see <a href="http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding">Maven FAQ</a>).
[INFO] [enforcer:enforce {execution: enforce}]
[TASKS] Skipping maven reporter: there is already a result available.
[INFO] [setproperty:set-property {execution: currentDate}]
[INFO] Property magnoliaCurrentDate set to value 8. November 2009 (scope: project)
[INFO] Property magnoliaReleaseDate set to value 8. November 2009 (scope: project)
[INFO] Property magnoliaNiceVersion set to value 4.2 (Snapshot: 08.11.2009 21:21:33) (scope: project)
[INFO] Property magnoliaNiceName set to value Magnolia Project (scope: project)
[TASKS] Skipping maven reporter: there is already a result available.
[INFO] Setting property: classpath.resource.loader.class => 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
[INFO] Setting property: velocimacro.messages.on => 'false'.
[INFO] Setting property: resource.loader => 'classpath'.
[INFO] Setting property: resource.manager.logwhenfound => 'false'.
[INFO] [remote-resources:process {execution: default}]
[TASKS] Skipping maven reporter: there is already a result available.
[INFO] [site:attach-descriptor]
[TASKS] Skipping maven reporter: there is already a result available.
[INFO] Preparing checkstyle:check
[INFO] Setting property: classpath.resource.loader.class => 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
[INFO] Setting property: velocimacro.messages.on => 'false'.
[INFO] Setting property: resource.loader => 'classpath'.
[INFO] Setting property: resource.manager.logwhenfound => 'false'.
[INFO] **************************************************************
[INFO] Starting Jakarta Velocity v1.4
[INFO] RuntimeInstance initializing.
[INFO] Default Properties File: org/apache/velocity/runtime/defaults/velocity.properties
[INFO] Default ResourceManager initializing. (class org.apache.velocity.runtime.resource.ResourceManagerImpl)
[INFO] Resource Loader Instantiated: org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader
[INFO] ClasspathResourceLoader : initialization starting.
[INFO] ClasspathResourceLoader : initialization complete.
[INFO] ResourceCache : initialized. (class org.apache.velocity.runtime.resource.ResourceCacheImpl)
[INFO] Default ResourceManager initialization complete.
[INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Literal
[INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Macro
[INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Parse
[INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Include
[INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Foreach
[INFO] Created: 20 parsers.
[INFO] Velocimacro : initialization starting.
[INFO] Velocimacro : adding VMs from VM library template : VM_global_library.vm
[ERROR] ResourceManager : unable to find resource 'VM_global_library.vm' in any resource loader.
[INFO] Velocimacro : error using VM library template VM_global_library.vm : org.apache.velocity.exception.ResourceNotFoundException: Unable to find resource 'VM_global_library.vm'
[INFO] Velocimacro : VM library template macro registration complete.
[INFO] Velocimacro : allowInline = true : VMs can be defined inline in templates
[INFO] Velocimacro : allowInlineToOverride = false : VMs defined inline may NOT replace previous VM definitions
[INFO] Velocimacro : allowInlineLocal = false : VMs defined inline will be global in scope if allowed.
[INFO] Velocimacro : initialization complete.
[INFO] Velocity successfully started.
[HUDSON] Archiving <http://hudson.magnolia-cms.com/job/magnolia_main-trunk/ws/trunk/pom.xml> to /usr/local/hudson/data/jobs/magnolia_main-trunk/modules/info.magnolia$magnolia-project/builds/2009-11-08_21-21-21/archive/info.magnolia/magnolia-project/4.2-SNAPSHOT/pom.xml
[INFO] [checkstyle:checkstyle]
[INFO] Source directory does not exist - skipping report.
[TASKS] Skipping maven reporter: there is already a result available.
[INFO] [checkstyle:check {execution: default}]
[INFO] Unable to perform checkstyle:check, unable to find checkstyle:checkstyle outputFile.
[TASKS] Skipping maven reporter: there is already a result available.
[INFO] [install:install]
[INFO] Installing <http://hudson.magnolia-cms.com/job/magnolia_main-trunk/ws/trunk/pom.xml> to /usr/local/hudson/maven-local-repo/info/magnolia/magnolia-project/4.2-SNAPSHOT/magnolia-project-4.2-SNAPSHOT.pom
[TASKS] Skipping maven reporter: there is already a result available.
[INFO] ------------------------------------------------------------------------
[INFO] Building magnolia-core
[INFO] task-segment: [clean, install]
[INFO] ------------------------------------------------------------------------
[INFO] [clean:clean]
[INFO] Deleting directory <http://hudson.magnolia-cms.com/job/magnolia_main-trunk/ws/trunk/magnolia-core/target>
[TASKS] Scanning folder '<http://hudson.magnolia-cms.com/job/magnolia_main-trunk/ws/trunk/magnolia-core/src/main/java'> for tasks ...
log4j:WARN No appenders could be found for logger (org.apache.commons.beanutils.converters.BooleanConverter).
log4j:WARN Please initialize the log4j system properly.
[TASKS] Found 146.
[TASKS] Scanning folder '<http://hudson.magnolia-cms.com/job/magnolia_main-trunk/ws/trunk/magnolia-core/src/main/resources'> for tasks ...
[TASKS] Found 1.
[TASKS] Scanning folder '<http://hudson.magnolia-cms.com/job/magnolia_main-trunk/ws/trunk/magnolia-core/src/main/resources'> for tasks ...
[TASKS] Found 1.
[TASKS] File encoding has not been set in pom.xml, using platform encoding MacRoman, i.e. build is platform dependent (see <a href="http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding">Maven FAQ</a>).
[INFO] [enforcer:enforce {execution: enforce}]
[TASKS] Skipping maven reporter: there is already a result available.
[INFO] [setproperty:set-property {execution: currentDate}]
[INFO] Property magnoliaCurrentDate set to value 8. November 2009 (scope: project)
[INFO] Property magnoliaReleaseDate set to value 8. November 2009 (scope: project)
[INFO] Property magnoliaNiceVersion set to value 4.2 (Snapshot: 08.11.2009 21:22:00) (scope: project)
[INFO] Property magnoliaNiceName set to value Magnolia Core (scope: project)
[TASKS] Skipping maven reporter: there is already a result available.
[INFO] [remote-resources:process {execution: default}]
[TASKS] Skipping maven reporter: there is already a result available.
[INFO] [resources:resources]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 42 resources
[INFO] Copying 3 resources
[INFO] Copying 3 resources
[TASKS] Skipping maven reporter: there is already a result available.
[INFO] [compiler:compile]
[INFO] Compiling 496 source files to <http://hudson.magnolia-cms.com/job/magnolia_main-trunk/ws/trunk/magnolia-core/target/classes>
[TASKS] Skipping maven reporter: there is already a result available.
[HUDSON] Archiving <http://hudson.magnolia-cms.com/job/magnolia_main-trunk/ws/trunk/magnolia-core/pom.xml> to /usr/local/hudson/data/jobs/magnolia_main-trunk/modules/info.magnolia$magnolia-core/builds/2009-11-08_21-21-21/archive/info.magnolia/magnolia-core/4.2-SNAPSHOT/pom.xml
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Compilation failure

<http://hudson.magnolia-cms.com/job/magnolia_main-trunk/ws/trunk/magnolia-core/src/main/java/info/magnolia/nodebuilder/Ops.java>:[250,28] cannot find symbol
symbol : constructor NodeTypeFilter(java.lang.String)
location: class info.magnolia.cms.util.NodeTypeFilter

<http://hudson.magnolia-cms.com/job/magnolia_main-trunk/ws/trunk/magnolia-core/src/main/java/info/magnolia/nodebuilder/Ops.java>:[287,25] cannot find symbol
symbol : constructor NodeTypeFilter(java.lang.String)
location: class info.magnolia.cms.util.NodeTypeFilter

[INFO] ------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 41 seconds
[INFO] Finished at: Sun Nov 08 21:22:06 CET 2009
[INFO] Final Memory: 34M/63M
[INFO] ------------------------------------------------------------------------
Waiting for Hudson to finish collecting data
Sending e-mails to: dev-list@... philipp.baerfuss@...
channel stopped

----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
----------------------------------------------------------------

Build failed in Hudson: magnolia_main-trunk » magnolia-core #1085

2009-11-08T12:22:08Z

See <http://hudson.magnolia-cms.com/job/magnolia_main-trunk/info.magnolia$magnolia-core/1085/changes>

Changes:

[pbaerfuss] MAGNOLIA-2897:
- rename
- move
- copy
- onChildNodes
- recursive

------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] Building magnolia-core
[INFO] task-segment: [clean, install]
[INFO] ------------------------------------------------------------------------
[INFO] [clean:clean]
[INFO] Deleting directory <http://hudson.magnolia-cms.com/job/magnolia_main-trunk/info.magnolia$magnolia-core/ws/target>
[TASKS] Scanning folder '<http://hudson.magnolia-cms.com/job/magnolia_main-trunk/info.magnolia$magnolia-core/ws/src/main/java'> for tasks ...
log4j:WARN No appenders could be found for logger (org.apache.commons.beanutils.converters.BooleanConverter).
log4j:WARN Please initialize the log4j system properly.
[TASKS] Found 146.
[TASKS] Scanning folder '<http://hudson.magnolia-cms.com/job/magnolia_main-trunk/info.magnolia$magnolia-core/ws/src/main/resources'> for tasks ...
[TASKS] Found 1.
[TASKS] Scanning folder '<http://hudson.magnolia-cms.com/job/magnolia_main-trunk/info.magnolia$magnolia-core/ws/src/main/resources'> for tasks ...
[TASKS] Found 1.
[TASKS] File encoding has not been set in pom.xml, using platform encoding MacRoman, i.e. build is platform dependent (see <a href="http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding">Maven FAQ</a>).
[INFO] [enforcer:enforce {execution: enforce}]
[TASKS] Skipping maven reporter: there is already a result available.
[INFO] [setproperty:set-property {execution: currentDate}]
[INFO] Property magnoliaCurrentDate set to value 8. November 2009 (scope: project)
[INFO] Property magnoliaReleaseDate set to value 8. November 2009 (scope: project)
[INFO] Property magnoliaNiceVersion set to value 4.2 (Snapshot: 08.11.2009 21:22:00) (scope: project)
[INFO] Property magnoliaNiceName set to value Magnolia Core (scope: project)
[TASKS] Skipping maven reporter: there is already a result available.
[INFO] [remote-resources:process {execution: default}]
[TASKS] Skipping maven reporter: there is already a result available.
[INFO] [resources:resources]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 42 resources
[INFO] Copying 3 resources
[INFO] Copying 3 resources
[TASKS] Skipping maven reporter: there is already a result available.
[INFO] [compiler:compile]
[INFO] Compiling 496 source files to <http://hudson.magnolia-cms.com/job/magnolia_main-trunk/info.magnolia$magnolia-core/ws/target/classes>
[TASKS] Skipping maven reporter: there is already a result available.
[HUDSON] Archiving <http://hudson.magnolia-cms.com/job/magnolia_main-trunk/info.magnolia$magnolia-core/ws/pom.xml> to /usr/local/hudson/data/jobs/magnolia_main-trunk/modules/info.magnolia$magnolia-core/builds/2009-11-08_21-21-21/archive/info.magnolia/magnolia-core/4.2-SNAPSHOT/pom.xml
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Compilation failure

<http://hudson.magnolia-cms.com/job/magnolia_main-trunk/info.magnolia$magnolia-core/ws/src/main/java/info/magnolia/nodebuilder/Ops.java>:[250,28] cannot find symbol
symbol : constructor NodeTypeFilter(java.lang.String)
location: class info.magnolia.cms.util.NodeTypeFilter

<http://hudson.magnolia-cms.com/job/magnolia_main-trunk/info.magnolia$magnolia-core/ws/src/main/java/info/magnolia/nodebuilder/Ops.java>:[287,25] cannot find symbol
symbol : constructor NodeTypeFilter(java.lang.String)
location: class info.magnolia.cms.util.NodeTypeFilter

[INFO] ------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 41 seconds
[INFO] Finished at: Sun Nov 08 21:22:06 CET 2009
[INFO] Final Memory: 34M/63M
[INFO] ------------------------------------------------------------------------
Waiting for Hudson to finish collecting data

----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
----------------------------------------------------------------

[JIRA] Commented: (MAGNOLIA-2671)
2009-11-07T14:26:36Z

[ http://jira.magnolia-cms.com/browse/MAGNOLIA-2671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=24773#action_24773 ]

Oliver Knorr commented on MAGNOLIA-2671:
----------------------------------------

I just had a fresh look at this, now with Magnolia 4.1.1, where the problem still exists. I tried to find a new fix without reverting to the old Resource.java version.

It obviously has to do with the single usage of the Resouce class in SimpleNavigationTag, which is the first line inside the doEndTag() method:
{code}
public int doEndTag() throws JspException {
Content activePage = Resource.getCurrentActivePage();
{code}
The problem disappeared for me, when I replaced getCurrentActivePage() with getActivePage(), like this:
{code}
public int doEndTag() throws JspException {
Content activePage = Resource.getActivePage();
{code}
I'm still a bit wary of suggesting this as a patch, as I don't know what the difference between getCurrentActivePage() and getActivePage() is supposed to be. Except for a deprecation notice, the Javadoc for the two methods is identical...

> <cmsu:simpleNavigation relativeLevels="true" fails
> --------------------------------------------------
>
> Key: MAGNOLIA-2671
> URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2671
> Project: Magnolia
> Issue Type: Bug
> Components: taglibs
> Affects Versions: 4.0.1, 4.1.1
> Environment: Windows Vista Business SP1
> JDK 1.6.0_11
> apache-tomcat-5.5.26
> magnolia-bundled-webapp-4.0.1.war
> Reporter: Oliver Knorr
> Assignee: Fabrizio Giustina
> Fix For: 4.1.2, 4.0.x
>
>
> After upgrading from Magnolia 3.6.3 to 4.0.1, the tag {{<cmsu:simpleNavigation relativeLevels="true" startLevel="0" endLevel="1" />}} does not print out the list of subpages anymore.
> Like with MAGNOLIA-2669, the problem seems to be caused by the changes for MAGNOLIA-2642 as it disappears for me when I revert Resource.java to the previous revision from http://svn.magnolia-cms.com/view/community/magnolia/trunk/magnolia-taglib-cms/src/main/java/info/magnolia/cms/taglibs/Resource.java?revision=21024

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.magnolia-cms.com/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
----------------------------------------------------------------

[JIRA] Updated: (MAGNOLIA-2671)
2009-11-07T13:37:36Z

[ http://jira.magnolia-cms.com/browse/MAGNOLIA-2671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Oliver Knorr updated MAGNOLIA-2671:
-----------------------------------

Affects Version/s: 4.1.1

> <cmsu:simpleNavigation relativeLevels="true" fails
> --------------------------------------------------
>
> Key: MAGNOLIA-2671
> URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2671
> Project: Magnolia
> Issue Type: Bug
> Components: taglibs
> Affects Versions: 4.0.1, 4.1.1
> Environment: Windows Vista Business SP1
> JDK 1.6.0_11
> apache-tomcat-5.5.26
> magnolia-bundled-webapp-4.0.1.war
> Reporter: Oliver Knorr
> Assignee: Fabrizio Giustina
> Fix For: 4.1.2, 4.0.x
>
>
> After upgrading from Magnolia 3.6.3 to 4.0.1, the tag {{<cmsu:simpleNavigation relativeLevels="true" startLevel="0" endLevel="1" />}} does not print out the list of subpages anymore.
> Like with MAGNOLIA-2669, the problem seems to be caused by the changes for MAGNOLIA-2642 as it disappears for me when I revert Resource.java to the previous revision from http://svn.magnolia-cms.com/view/community/magnolia/trunk/magnolia-taglib-cms/src/main/java/info/magnolia/cms/taglibs/Resource.java?revision=21024

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.magnolia-cms.com/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
----------------------------------------------------------------

Hudson build is back to stable: magnolia_main-trunk-forked-tests #384

2009-11-06T16:03:58Z

See <http://hudson.magnolia-cms.com/job/magnolia_main-trunk-forked-tests/384/>

----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
----------------------------------------------------------------

Hudson build is back to stable: magnolia_main-trunk-forked-tests » magnolia-module-exchange-simple #384

2009-11-06T16:03:56Z

See <http://hudson.magnolia-cms.com/job/magnolia_main-trunk-forked-tests/info.magnolia$magnolia-module-exchange-simple/384/>

----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
----------------------------------------------------------------

Hudson build became unstable: magnolia_main-trunk-forked-tests #383

2009-11-06T15:08:28Z

See <http://hudson.magnolia-cms.com/job/magnolia_main-trunk-forked-tests/383/changes>

----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
----------------------------------------------------------------

Hudson build became unstable: magnolia_main-trunk-forked-tests » magnolia-module-exchange-simple #383

2009-11-06T15:08:26Z

See <http://hudson.magnolia-cms.com/job/magnolia_main-trunk-forked-tests/info.magnolia$magnolia-module-exchange-simple/383/>

----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
----------------------------------------------------------------

[JIRA] Commented: (MAGNOLIA-2901) Moving nodes in adminCentral shows moved node content as parent node content

2009-11-06T14:23:36Z

[ http://jira.magnolia-cms.com/browse/MAGNOLIA-2901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=24772#action_24772 ]

Grégory Joseph commented on MAGNOLIA-2901:
------------------------------------------

What's the status of this issue ?

(the rootPath can be used by tree definitions to only show a subtree)

> Moving nodes in adminCentral shows moved node content as parent node content
> ----------------------------------------------------------------------------
>
> Key: MAGNOLIA-2901
> URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2901
> Project: Magnolia
> Issue Type: Bug
> Components: admininterface
> Affects Versions: 4.1.1
> Environment: Browsers I tested on:
> Firefox
> Safari
> Reporter: Christian Ringele
> Assignee: Philipp Bärfuss
> Priority: Critical
> Fix For: 4.1.2, 4.2
>
> Attachments: MAGNOLIA-2901-after-move.png, MAGNOLIA-2901-before-move.png
>
>
> When moving a node in admin central to a different parent node, the tree only shows the content of the moved node (subnodes) instead of the whole tree.
> The move occurs properly, and this is "only" a visual issue.
> It doesn't seem to be specific to any workspace (reproduced on config, website, dms, ...) nor instance (reproduced on several local ones, demoauthor, ...)

[JIRA] Created: (MAGNOLIA-2930) Remove leftover usages of RequestFormUtil

2009-11-06T09:13:36Z

Remove leftover usages of RequestFormUtil
-----------------------------------------

Key: MAGNOLIA-2930
URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2930
Project: Magnolia
Issue Type: Task
Reporter: Grégory Joseph
Assignee: Boris Kraft
Fix For: 4.3

Since MAGNOLIA-2449, RequestFormUtil shouldn't be needed anymore. It's been deprecated since 4.0, time to remove it completely!

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.magnolia-cms.com/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
----------------------------------------------------------------

Hudson build is back to stable: magnolia_main-trunk #1084

2009-11-06T09:08:24Z

See <http://hudson.magnolia-cms.com/job/magnolia_main-trunk/1084/>

----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
----------------------------------------------------------------

Hudson build is back to stable: magnolia_main-trunk » magnolia-module-exchange-simple #1084

2009-11-06T09:08:22Z

See <http://hudson.magnolia-cms.com/job/magnolia_main-trunk/info.magnolia$magnolia-module-exchange-simple/1084/>

----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
----------------------------------------------------------------

[JIRA] Commented: (MAGNOLIA-2897) Introduce a simpler api to build nodes/properties

2009-11-06T08:20:36Z

[ http://jira.magnolia-cms.com/browse/MAGNOLIA-2897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=24768#action_24768 ]

Hudson CI server commented on MAGNOLIA-2897:
--------------------------------------------

Integrated in !http://hudson.magnolia-cms.com/nocacheImages/16x16/yellow.gif! [magnolia_main-trunk #1083|http://hudson.magnolia-cms.com/job/magnolia_main-trunk/1083/]
extracted AbstractNodeBuilderTask and introduced ModuleNodeBuilderTask

Hudson build became unstable: magnolia_main-trunk #1083

2009-11-06T08:20:34Z

See <http://hudson.magnolia-cms.com/job/magnolia_main-trunk/1083/changes>

----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
----------------------------------------------------------------

Hudson build became unstable: magnolia_main-trunk » magnolia-module-exchange-simple #1083

2009-11-06T08:20:32Z

See <http://hudson.magnolia-cms.com/job/magnolia_main-trunk/info.magnolia$magnolia-module-exchange-simple/1083/>

----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
----------------------------------------------------------------

[JIRA] Commented: (MAGNOLIA-2897) Introduce a simpler api to build nodes/properties

2009-11-06T07:35:36Z

[ http://jira.magnolia-cms.com/browse/MAGNOLIA-2897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=24765#action_24765 ]

Hudson CI server commented on MAGNOLIA-2897:
--------------------------------------------

Integrated in !http://hudson.magnolia-cms.com/nocacheImages/16x16/blue.gif! [magnolia_main-trunk #1082|http://hudson.magnolia-cms.com/job/magnolia_main-trunk/1082/]
Added NodeOperation addNode(final String name, final ItemType type)

Re: making PUR module more flexible

2009-11-06T07:16:26Z

Hi Bert,

Thanks for the taking the time to write this! Now I think I understand
your requests! ;)

On Nov 6, 2009, at 10:40 AM, Bert Leunis wrote:

> Hello Grégory (and others),
>
> I will give it one more go to see if I can get my points across!
>
> Our client will use PUR in a slightly different way than the
> standard scenario that PUR presumes/implies. When adapting the
> different scenario I saw two points in the code that can make PUR
> more flexible quite easily. With more flexible I mean: it does not
> hinder the standard scenario but it helps you when your scenario is
> different (like mine).
>
> This is the new scenario we use:
>
> 1. The webeditor will register the Public User, it wil not be the
> User itself. (a Public User is created, and a node in the datamodule
> to store the users data).
> 2. The User gets an e-mail with its user name and a validation link.
> 3. The User clicks on the link to validate himself. (The Public User
> is enabled).
> 4. The User gets an e-mail with a generated password and a link to
> the login page.

In your scenario, is the "self registration" *also* needed?

> I need some changes in PUR to make this possible. Next to the
> registrationStrategy and the passwordRetrievalStrategy I need a new
> sendPasswordStrategy. I can store that at config/modules/public-user-
> registration/config next to the other two, no problem at all. But,
> if I want to retrieve that strategy in my code, I cannot use the
> info
> .magnolia
> .module.publicuserregistration.PublicUserRegistrationConfig, because
> it doesn't have a private field and getters/setters to store my new
> strategy. Now I need to change the code of that class. And here is
> my proposal: if all strategies were stored in the config and in the
> PublicUserRegistrationConfig class in a list or Map, then everybody
> who wants to add strategies of their own can add them, without
> having to change the code. Config instead of coding. See the picture
> to get my idea:
>
> <image002.jpg>
> You would get the strategy you want by its name.

They're different interfaces with different use-cases; if multiple
implementations of either are needed, we could imagine something like
this but with a map for each (i.e they're not "two strategies" they
are "one PasswordRetrievalStrategy" (impl of the mechanism for users
to retrieve their passwords) and "one RegistrationStrategy" (impl of
the mechanism used to register and validate users)

> Second idea comes from the wish to send a slightly different e-mail
> than the ones that are used in a standard situation. The class
> info.magnolia.module.publicuserregistration.strategy.Mail is used to
> send the e-mail. This class has all the properties you need to send
> an e-mail (fromName, fromEmail, subject, emailTemplate etc).
> Unfortunately, in the emailTemplate you can only use one variable,
> which is “pagePath”. The method validateRegistration(User user) sets
> only that one variable. Now, if there was an extra method with this
> signature: public void validateRegistration(User user, Map<String,
> Object> templateValues), then every strategy wanting to send e-mails
> to the Public User would be able to apply all the variables they
> wanted. A very easy change of the code, which makes it much more
> usable.

Where would these values come from, who (what code) would set them ?

Cheers,

-g

>
> Happy to apply any patch, if you can see the benefit.
>
> Lots of regards, Bert
>
>
>
> > -----Original Message-----
> > From: dev-list-owner@... [mailto:dev-list-owner@magnolia-
> > cms.com] On Behalf Of Grégory Joseph
> > Sent: vrijdag 9 oktober 2009 14:39
> > To: Magnolia Dev-List
> > Subject: Re: [magnolia-dev] making PUR module more flexible
> >
> >
> >
> > On Oct 9, 2009, at 8:48 AM, Bert Leunis wrote:
> >
> > >
> > > Hi Grégory,
> > >
> > > Thanks for the effort. Of course I can adapt and override code as
> > > much as I like. My whole point is, that I like to do more
> > > configuration instead of coding.
> >
> >
> > That's a valid point, but I still don't see what you're trying to
> > achieve, concretely.
> >
> > > And I hoped my suggestions would lead to a little improvement in
> > > that direction. But if you don't see the benefit (or I am not
> clear
> > > enough about them)
> >
> > Most likely the latter; or I'm too thick;)
> >
> >
> > > let's just leave it as it is. You should delete the 2 jira's then
> > > (MGNLPUR-22 and -23).
> > >
> > > Bye, Bert
> > >
> > >
> > >> -----Original Message-----
> > >> From: dev-list-owner@... [mailto:dev-list-
> > >> owner@magnolia-
> > >> cms.com] On Behalf Of Grégory Joseph
> > >> Sent: donderdag 8 oktober 2009 18:22
> > >> To: Magnolia Dev-List
> > >> Subject: Re: [magnolia-dev] making PUR module more flexible
> > >>
> > >>
> > >>
> > >> On Oct 8, 2009, at 3:05 PM, Bert Leunis wrote:
> > >>>>> 1. Add a new method to
> > >>>>> info.magnolia.module.publicuserregistration.strategy.Mail:
> public
> > >>>>> void validateRegistration(User user, Map<String, Object>
> > >>>>> templateValues). This way the process using that class can add
> > >> their
> > >>>>> templateValues themselves.
> > >>>>
> > >>>> It's the UserRegistrar which calls this method; if you need
> more
> > >>>> parameters in your mail templates, you probably want to
> subclass
> > >>>> i.m.m.pur.strategy.Mail anyway? Where do these parameters come
> > >>>> from?
> > >>>> Why would you allow arbitrary parameters to be passed there,
> > what's
> > >>>> the actual usecase? (as a side note, if this ends up being
> really
> > >>>> necessary, i'd rather change the method than add one)
> > >>>
> > >>> You can have extra parameters in your mail template, e.g. $
> > >>> {generatedPassword}. The EnableByUUID class will send the user a
> > >>> mail with that password, so that class adds all necessary
> params to
> > >>> the Map<String, Object>. No need to create your own strategy,
> all
> > >>> fields in Mail are oke, all I want is to fill the context with
> my
> > >>> own specific values.
> > >>
> > >> What is "EnableByUUID" ? An implementation of
> > >>
> info.magnolia.module.publicuserregistration.RegistrationStrategy ?
> > So
> > >> why can't it add the template values itself in
> > >> info
> > >> .magnolia
> >
> >> .module.publicuserregistration.strategy.Mail#validateRegistration ?
> > >> (if that's what you're doing, of course we could extract a
> > >> addTemplateContextValues() in there)
> > >>
> > >>
> > >>>>> 2. When you need an extra strategy, you have to adapt
> the
> > >>>>> PublicUserRegistrationConfig class.
> > >>>>
> > >>>> Uh? How so? As far as I know, you only need to configure it
> in /
> > >>>> modules/pur/config/registrationStrategy or ../
> > >>>> passwordRetrievalStrategy
> > >>>>
> > >>>>> Instead of having a fixed set of 3 strategies, a list of
> > >>>>> strategies
> > >>>>> could be present in the config.
> > >>>>
> > >>>> Unless i missed something, it's not a fixed set and was indeed
> > >>>> meant
> > >>>> so that one can have their custom strategies
> > >>>>
> > >>>
> > >>> My point is: I want to ADD another strategy
> (sendPasswordStrategy).
> > >>> The flow I need for my case here is different than the flow
> that is
> > >>> now 'dictated' by PUR. As far as I can see, it is a fixed set
> now.
> > >>> The class PublicUserRegistrationConfig has two strategies-
> > >>> properties. If they are stored in a map, I do not have to
> write any
> > >>> code, just add some config.
> > >>>
> > >>
> > >> But these 2 strategies are there for different purposes, and are
> > used
> > >> in different contexts ! They're different interfaces, too!
> > Obviously,
> > >> if you need another functionality (which is...?), you'll need to
> > code
> > >> stuff; which could be in a different module.
> > >>
> > >>
> > >>
> > >>>
> > >>>>> Probably a module class has to be created that loads the
> > >>>>> strategies
> > >>>>> in a Map<String, Strategy>. From the module instance the
> strategy
> > >>>>> can then be retrieved by name. (I created a
> > sendPasswordStrategy).
> > >>>>
> > >>>> I'm not sure what you mean, but then again, see above comments.
> > >>>
> > >>> I don't think the content2bean utils will convert a list of
> > >>> strategies in a Map<String, Strategy> automatically. That can be
> > >>> done in the module class (like it is done in the DataModule).
> > >>
> > >> Actually, content2bean will convert that, but I don't see the
> > >> usecase.
> > >> PUR provides two hooks: RegistrationStrategy(validation of a
> user's
> > >> registration - customize if you want to prevent users to register
> > >> on a
> > >> sunday), and PasswordRetrievalStrategy (determines how users can
> > >> retrieve their password - or have it changed).
> > >>
> > >> Both interfaces can be swapped in configuration, so you can use
> your
> > >> own implementations. We currently have a single impl for
> > >> PasswordRetrievalStrategy, and 3 for RegistrationStrategy.
> > >>
> > >> If you use your IDE to search for usages of these interfaces,
> you'll
> > >> see they're used in totally different contexts. They're not "a"
> > >> strategy. They're just two different pluggable components
> provided
> > by
> > >> this module. I'm tempted to rename these interfaces to
> > >> PasswordRetrieval and RegistrationValidation if it's so
> confusing.
> > >>
> > >> hth,
> > >>
> > >> -g
> > >>
> > >>
> > >> ----------------------------------------------------------------
> > >> For list details see
> > >> http://www.magnolia-cms.com/home/community/mailing-lists.html
> > >> To unsubscribe, E-mail to: <dev-list-unsubscribe@magnolia-
> cms.com>
> > >> ----------------------------------------------------------------
> > >
> > >
> > > ----------------------------------------------------------------
> > > For list details see
> > > http://www.magnolia-cms.com/home/community/mailing-lists.html
> > > To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
> > > ----------------------------------------------------------------
> >
> >
> > ----------------------------------------------------------------
> > For list details see
> > http://www.magnolia-cms.com/home/community/mailing-lists.html
> > To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
> > ----------------------------------------------------------------
>
>
>
> ----------------------------------------------------------------
> For list details see
> http://www.magnolia-cms.com/home/community/mailing-lists.html
> To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
> ----------------------------------------------------------------

----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
----------------------------------------------------------------

[JIRA] Commented: (MAGNOLIA-2897) Introduce a simpler api to build nodes/properties

2009-11-06T07:06:38Z

[ http://jira.magnolia-cms.com/browse/MAGNOLIA-2897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=24764#action_24764 ]

Hudson CI server commented on MAGNOLIA-2897:
--------------------------------------------

Integrated in !http://hudson.magnolia-cms.com/nocacheImages/16x16/blue.gif! [magnolia_main-trunk #1081|http://hudson.magnolia-cms.com/job/magnolia_main-trunk/1081/]
* renamed add() to addNode()
* renamed Ops.A to Ops.AbstractOp
* javadoc

RE: making PUR module more flexible

2009-11-06T01:56:30Z

Hi Bert,

please comment on MGNLPUR-22/23 to raise the discussion.
Thanks.

-
Best regards,

Zdenek Skodik
Magnolia International Ltd.

Magnolia® - Simple Open-Source Content Management

On Pá, 2009-11-06 at 10:40 +0100, Bert Leunis wrote:

> Hello Grégory (and others),
>
>
>
> I will give it one more go to see if I can get my points across!
>
>
>
> Our client will use PUR in a slightly different way than the standard
> scenario that PUR presumes/implies. When adapting the different
> scenario I saw two points in the code that can make PUR more flexible
> quite easily. With more flexible I mean: it does not hinder the
> standard scenario but it helps you when your scenario is different
> (like mine).
>
>
>
> This is the new scenario we use:
>
>
>
> 1. The webeditor will register the Public User, it wil not be the User
> itself. (a Public User is created, and a node in the datamodule to
> store the users data).
>
> 2. The User gets an e-mail with its user name and a validation link.
>
> 3. The User clicks on the link to validate himself. (The Public User
> is enabled).
>
> 4. The User gets an e-mail with a generated password and a link to the
> login page.
>
>
>
> I need some changes in PUR to make this possible. Next to the
> registrationStrategy and the passwordRetrievalStrategy I need a new
> sendPasswordStrategy. I can store that at
> config/modules/public-user-registration/config next to the other two,
> no problem at all. But, if I want to retrieve that strategy in my
> code, I cannot use the
> info.magnolia.module.publicuserregistration.PublicUserRegistrationConfig, because it doesn't have a private field and getters/setters to store my new strategy. Now I need to change the code of that class. And here is my proposal: if all strategies were stored in the config and in the PublicUserRegistrationConfig class in a list or Map, then everybody who wants to add strategies of their own can add them, without having to change the code. Config instead of coding. See the picture to get my idea:
>
>
>
>
>
> You would get the strategy you want by its name.
>
>
>
> Second idea comes from the wish to send a slightly different e-mail
> than the ones that are used in a standard situation. The class
> info.magnolia.module.publicuserregistration.strategy.Mail is used to
> send the e-mail. This class has all the properties you need to send an
> e-mail (fromName, fromEmail, subject, emailTemplate etc).
> Unfortunately, in the emailTemplate you can only use one variable,
> which is “pagePath”. The method validateRegistration(User user) sets
> only that one variable. Now, if there was an extra method with this
> signature: public void validateRegistration(User user, Map<String,
> Object> templateValues), then every strategy wanting to send e-mails
> to the Public User would be able to apply all the variables they
> wanted. A very easy change of the code, which makes it much more
> usable.
>
>
>
> Happy to apply any patch, if you can see the benefit.
>
>
>
> Lots of regards, Bert
>
>
>
>
>
>
>
> > -----Original Message-----
>
> > From: dev-list-owner@...
> [mailto:dev-list-owner@magnolia-
>
> > cms.com] On Behalf Of Grégory Joseph
>
> > Sent: vrijdag 9 oktober 2009 14:39
>
> > To: Magnolia Dev-List
>
> > Subject: Re: [magnolia-dev] making PUR module more flexible
>
> >
>
> >
>
> >
>
> > On Oct 9, 2009, at 8:48 AM, Bert Leunis wrote:
>
> >
>
> > >
>
> > > Hi Grégory,
>
> > >
>
> > > Thanks for the effort. Of course I can adapt and override code as
>
> > > much as I like. My whole point is, that I like to do more
>
> > > configuration instead of coding.
>
> >
>
> >
>
> > That's a valid point, but I still don't see what you're trying to
>
> > achieve, concretely.
>
> >
>
> > > And I hoped my suggestions would lead to a little improvement in
>
> > > that direction. But if you don't see the benefit (or I am not
> clear
>
> > > enough about them)
>
> >
>
> > Most likely the latter; or I'm too thick;)
>
> >
>
> >
>
> > > let's just leave it as it is. You should delete the 2 jira's then
>
> > > (MGNLPUR-22 and -23).
>
> > >
>
> > > Bye, Bert
>
> > >
>
> > >
>
> > >> -----Original Message-----
>
> > >> From: dev-list-owner@... [mailto:dev-list-
>
> > >> owner@magnolia-
>
> > >> cms.com] On Behalf Of Grégory Joseph
>
> > >> Sent: donderdag 8 oktober 2009 18:22
>
> > >> To: Magnolia Dev-List
>
> > >> Subject: Re: [magnolia-dev] making PUR module more flexible
>
> > >>
>
> > >>
>
> > >>
>
> > >> On Oct 8, 2009, at 3:05 PM, Bert Leunis wrote:
>
> > >>>>> 1. Add a new method to
>
> > >>>>> info.magnolia.module.publicuserregistration.strategy.Mail:
> public
>
> > >>>>> void validateRegistration(User user, Map<String, Object>
>
> > >>>>> templateValues). This way the process using that class can add
>
> > >> their
>
> > >>>>> templateValues themselves.
>
> > >>>>
>
> > >>>> It's the UserRegistrar which calls this method; if you need
> more
>
> > >>>> parameters in your mail templates, you probably want to
> subclass
>
> > >>>> i.m.m.pur.strategy.Mail anyway? Where do these parameters come
>
> > >>>> from?
>
> > >>>> Why would you allow arbitrary parameters to be passed there,
>
> > what's
>
> > >>>> the actual usecase? (as a side note, if this ends up being
> really
>
> > >>>> necessary, i'd rather change the method than add one)
>
> > >>>
>
> > >>> You can have extra parameters in your mail template, e.g. $
>
> > >>> {generatedPassword}. The EnableByUUID class will send the user a
>
> > >>> mail with that password, so that class adds all necessary params
> to
>
> > >>> the Map<String, Object>. No need to create your own strategy,
> all
>
> > >>> fields in Mail are oke, all I want is to fill the context with
> my
>
> > >>> own specific values.
>
> > >>
>
> > >> What is "EnableByUUID" ? An implementation of
>
> > >>
> info.magnolia.module.publicuserregistration.RegistrationStrategy ?
>
> > So
>
> > >> why can't it add the template values itself in
>
> > >> info
>
> > >> .magnolia
>
> >
> >> .module.publicuserregistration.strategy.Mail#validateRegistration ?
>
> > >> (if that's what you're doing, of course we could extract a
>
> > >> addTemplateContextValues() in there)
>
> > >>
>
> > >>
>
> > >>>>> 2. When you need an extra strategy, you have to adapt
> the
>
> > >>>>> PublicUserRegistrationConfig class.
>
> > >>>>
>
> > >>>> Uh? How so? As far as I know, you only need to configure it
> in /
>
> > >>>> modules/pur/config/registrationStrategy or ../
>
> > >>>> passwordRetrievalStrategy
>
> > >>>>
>
> > >>>>> Instead of having a fixed set of 3 strategies, a list of
>
> > >>>>> strategies
>
> > >>>>> could be present in the config.
>
> > >>>>
>
> > >>>> Unless i missed something, it's not a fixed set and was indeed
>
> > >>>> meant
>
> > >>>> so that one can have their custom strategies
>
> > >>>>
>
> > >>>
>
> > >>> My point is: I want to ADD another strategy
> (sendPasswordStrategy).
>
> > >>> The flow I need for my case here is different than the flow that
> is
>
> > >>> now 'dictated' by PUR. As far as I can see, it is a fixed set
> now.
>
> > >>> The class PublicUserRegistrationConfig has two strategies-
>
> > >>> properties. If they are stored in a map, I do not have to write
> any
>
> > >>> code, just add some config.
>
> > >>>
>
> > >>
>
> > >> But these 2 strategies are there for different purposes, and are
>
> > used
>
> > >> in different contexts ! They're different interfaces, too!
>
> > Obviously,
>
> > >> if you need another functionality (which is...?), you'll need to
>
> > code
>
> > >> stuff; which could be in a different module.
>
> > >>
>
> > >>
>
> > >>
>
> > >>>
>
> > >>>>> Probably a module class has to be created that loads the
>
> > >>>>> strategies
>
> > >>>>> in a Map<String, Strategy>. From the module instance the
> strategy
>
> > >>>>> can then be retrieved by name. (I created a
>
> > sendPasswordStrategy).
>
> > >>>>
>
> > >>>> I'm not sure what you mean, but then again, see above comments.
>
> > >>>
>
> > >>> I don't think the content2bean utils will convert a list of
>
> > >>> strategies in a Map<String, Strategy> automatically. That can be
>
> > >>> done in the module class (like it is done in the DataModule).
>
> > >>
>
> > >> Actually, content2bean will convert that, but I don't see the
>
> > >> usecase.
>
> > >> PUR provides two hooks: RegistrationStrategy(validation of a
> user's
>
> > >> registration - customize if you want to prevent users to register
>
> > >> on a
>
> > >> sunday), and PasswordRetrievalStrategy (determines how users can
>
> > >> retrieve their password - or have it changed).
>
> > >>
>
> > >> Both interfaces can be swapped in configuration, so you can use
> your
>
> > >> own implementations. We currently have a single impl for
>
> > >> PasswordRetrievalStrategy, and 3 for RegistrationStrategy.
>
> > >>
>
> > >> If you use your IDE to search for usages of these interfaces,
> you'll
>
> > >> see they're used in totally different contexts. They're not "a"
>
> > >> strategy. They're just two different pluggable components
> provided
>
> > by
>
> > >> this module. I'm tempted to rename these interfaces to
>
> > >> PasswordRetrieval and RegistrationValidation if it's so
> confusing.
>
> > >>
>
> > >> hth,
>
> > >>
>
> > >> -g
>
> > >>
>
> > >>
>
> > >> ----------------------------------------------------------------
>
> > >> For list details see
>
> > >> http://www.magnolia-cms.com/home/community/mailing-lists.html
>
> > >> To unsubscribe, E-mail to:
> <dev-list-unsubscribe@...>
>
> > >> ----------------------------------------------------------------
>
> > >
>
> > >
>
> > > ----------------------------------------------------------------
>
> > > For list details see
>
> > > http://www.magnolia-cms.com/home/community/mailing-lists.html
>
> > > To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
>
> > > ----------------------------------------------------------------
>
> >
>
> >
>
> > ----------------------------------------------------------------
>
> > For list details see
>
> > http://www.magnolia-cms.com/home/community/mailing-lists.html
>
> > To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
>
> > ----------------------------------------------------------------
>
>
>
>
>
>
>
> ______________________________________________________________________
> ----------------------------------------------------------------
> For list details see
> http://www.magnolia-cms.com/home/community/mailing-lists.html
> To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
> ----------------------------------------------------------------

RE: making PUR module more flexible

2009-11-06T01:40:40Z

Hello Grégory (and others),

I will give it one more go to see if I can get my points across!

Our client will use PUR in a slightly different way than the standard scenario that PUR presumes/implies. When adapting the different scenario I saw two points in the code that can make PUR more flexible quite easily. With more flexible I mean: it does not hinder the standard scenario but it helps you when your scenario is different (like mine).

This is the new scenario we use:

1. The webeditor will register the Public User, it wil not be the User itself. (a Public User is created, and a node in the datamodule to store the users data).

2. The User gets an e-mail with its user name and a validation link.

3. The User clicks on the link to validate himself. (The Public User is enabled).

4. The User gets an e-mail with a generated password and a link to the login page.

I need some changes in PUR to make this possible. Next to the registrationStrategy and the passwordRetrievalStrategy I need a new sendPasswordStrategy. I can store that at config/modules/public-user-registration/config next to the other two, no problem at all. But, if I want to retrieve that strategy in my code, I cannot use the info.magnolia.module.publicuserregistration.PublicUserRegistrationConfig, because it doesn't have a private field and getters/setters to store my new strategy. Now I need to change the code of that class. And here is my proposal: if all strategies were stored in the config and in the PublicUserRegistrationConfig class in a list or Map, then everybody who wants to add strategies of their own can add them, without having to change the code. Config instead of coding. See the picture to get my idea:

You would get the strategy you want by its name.

Second idea comes from the wish to send a slightly different e-mail than the ones that are used in a standard situation. The class info.magnolia.module.publicuserregistration.strategy.Mail is used to send the e-mail. This class has all the properties you need to send an e-mail (fromName, fromEmail, subject, emailTemplate etc). Unfortunately, in the emailTemplate you can only use one variable, which is “pagePath”. The method validateRegistration(User user) sets only that one variable. Now, if there was an extra method with this signature: public void validateRegistration(User user, Map<String, Object> templateValues), then every strategy wanting to send e-mails to the Public User would be able to apply all the variables they wanted. A very easy change of the code, which makes it much more usable.

Happy to apply any patch, if you can see the benefit.

Lots of regards, Bert

> -----Original Message-----

> From: dev-list-owner@... [mailto:dev-list-owner@magnolia-

> cms.com] On Behalf Of Grégory Joseph

> Sent: vrijdag 9 oktober 2009 14:39

> To: Magnolia Dev-List

> Subject: Re: [magnolia-dev] making PUR module more flexible

> On Oct 9, 2009, at 8:48 AM, Bert Leunis wrote:

> >

> > Hi Grégory,

> >

> > Thanks for the effort. Of course I can adapt and override code as

> > much as I like. My whole point is, that I like to do more

> > configuration instead of coding.

> That's a valid point, but I still don't see what you're trying to

> achieve, concretely.

> > And I hoped my suggestions would lead to a little improvement in

> > that direction. But if you don't see the benefit (or I am not clear

> > enough about them)

> Most likely the latter; or I'm too thick;)

> > let's just leave it as it is. You should delete the 2 jira's then

> > (MGNLPUR-22 and -23).

> >

> > Bye, Bert

> >

> >> -----Original Message-----

> >> From: dev-list-owner@... [mailto:dev-list-

> >> owner@magnolia-

> >> cms.com] On Behalf Of Grégory Joseph

> >> Sent: donderdag 8 oktober 2009 18:22

> >> To: Magnolia Dev-List

> >> Subject: Re: [magnolia-dev] making PUR module more flexible

> >>

> >> On Oct 8, 2009, at 3:05 PM, Bert Leunis wrote:

> >>>>> 1. Add a new method to

> >>>>> info.magnolia.module.publicuserregistration.strategy.Mail: public

> >>>>> void validateRegistration(User user, Map<String, Object>

> >>>>> templateValues). This way the process using that class can add

> >> their

> >>>>> templateValues themselves.

> >>>>

> >>>> It's the UserRegistrar which calls this method; if you need more

> >>>> parameters in your mail templates, you probably want to subclass

> >>>> i.m.m.pur.strategy.Mail anyway? Where do these parameters come

> >>>> from?

> >>>> Why would you allow arbitrary parameters to be passed there,

> what's

> >>>> the actual usecase? (as a side note, if this ends up being really

> >>>> necessary, i'd rather change the method than add one)

> >>>

> >>> You can have extra parameters in your mail template, e.g. $

> >>> {generatedPassword}. The EnableByUUID class will send the user a

> >>> mail with that password, so that class adds all necessary params to

> >>> the Map<String, Object>. No need to create your own strategy, all

> >>> fields in Mail are oke, all I want is to fill the context with my

> >>> own specific values.

> >>

> >> What is "EnableByUUID" ? An implementation of

> >> info.magnolia.module.publicuserregistration.RegistrationStrategy ?

> So

> >> why can't it add the template values itself in

> >> info

> >> .magnolia

> >> .module.publicuserregistration.strategy.Mail#validateRegistration ?

> >> (if that's what you're doing, of course we could extract a

> >> addTemplateContextValues() in there)

> >>

> >>>>> 2. When you need an extra strategy, you have to adapt the

> >>>>> PublicUserRegistrationConfig class.

> >>>>

> >>>> Uh? How so? As far as I know, you only need to configure it in /

> >>>> modules/pur/config/registrationStrategy or ../

> >>>> passwordRetrievalStrategy

> >>>>

> >>>>> Instead of having a fixed set of 3 strategies, a list of

> >>>>> strategies

> >>>>> could be present in the config.

> >>>>

> >>>> Unless i missed something, it's not a fixed set and was indeed

> >>>> meant

> >>>> so that one can have their custom strategies

> >>>>

> >>>

> >>> My point is: I want to ADD another strategy (sendPasswordStrategy).

> >>> The flow I need for my case here is different than the flow that is

> >>> now 'dictated' by PUR. As far as I can see, it is a fixed set now.

> >>> The class PublicUserRegistrationConfig has two strategies-

> >>> properties. If they are stored in a map, I do not have to write any

> >>> code, just add some config.

> >>>

> >>

> >> But these 2 strategies are there for different purposes, and are

> used

> >> in different contexts ! They're different interfaces, too!

> Obviously,

> >> if you need another functionality (which is...?), you'll need to

> code

> >> stuff; which could be in a different module.

> >>

> >>>

> >>>>> Probably a module class has to be created that loads the

> >>>>> strategies

> >>>>> in a Map<String, Strategy>. From the module instance the strategy

> >>>>> can then be retrieved by name. (I created a

> sendPasswordStrategy).

> >>>>

> >>>> I'm not sure what you mean, but then again, see above comments.

> >>>

> >>> I don't think the content2bean utils will convert a list of

> >>> strategies in a Map<String, Strategy> automatically. That can be

> >>> done in the module class (like it is done in the DataModule).

> >>

> >> Actually, content2bean will convert that, but I don't see the

> >> usecase.

> >> PUR provides two hooks: RegistrationStrategy(validation of a user's

> >> registration - customize if you want to prevent users to register

> >> on a

> >> sunday), and PasswordRetrievalStrategy (determines how users can

> >> retrieve their password - or have it changed).

> >>

> >> Both interfaces can be swapped in configuration, so you can use your

> >> own implementations. We currently have a single impl for

> >> PasswordRetrievalStrategy, and 3 for RegistrationStrategy.

> >>

> >> If you use your IDE to search for usages of these interfaces, you'll

> >> see they're used in totally different contexts. They're not "a"

> >> strategy. They're just two different pluggable components provided

> by

> >> this module. I'm tempted to rename these interfaces to

> >> PasswordRetrieval and RegistrationValidation if it's so confusing.

> >>

> >> hth,

> >>

> >> -g

> >>

> >> ----------------------------------------------------------------

> >> For list details see

> >> http://www.magnolia-cms.com/home/community/mailing-lists.html

> >> To unsubscribe, E-mail to: <dev-list-unsubscribe@...>

> >> ----------------------------------------------------------------

> >

> > ----------------------------------------------------------------

> > For list details see

> > http://www.magnolia-cms.com/home/community/mailing-lists.html

> > To unsubscribe, E-mail to: <dev-list-unsubscribe@...>

> > ----------------------------------------------------------------

> ----------------------------------------------------------------

> For list details see

> http://www.magnolia-cms.com/home/community/mailing-lists.html

> To unsubscribe, E-mail to: <dev-list-unsubscribe@...>

> ----------------------------------------------------------------

[JIRA] Updated: (MAGNOLIA-2929) Enhance unicode support

2009-11-06T00:25:36Z

[ http://jira.magnolia-cms.com/browse/MAGNOLIA-2929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Haderka updated MAGNOLIA-2929:
----------------------------------

Description:
In light of MGNLWEBDAV-15, we need Magnolia to be a little more lax with unicode names.

There are two sides to this issue:
* the current {{SimpleUrlPattern}} implementation chokes on paths with unicode characters in the decomposed form.
* Jackrabbit does no unicode normalization for node names, thus a node created with a name in the composed form can not be retrieved by using the decomposed form of the exact same name.

Since "clients" tend to use one or the other form arbitrarily (Firefox 3.0 on MacOSX sends GET parameters in the NFD form, Safari in NFC; while the Linux OS tends to favor NFC and OSX tends to favor NFD, for instance).

Node name normalization unfortunately requires using either Java 6 ([{{java.text.Normalizer}}|http://java.sun.com/javase/6/docs/api/java/text/Normalizer.html]), the [ICU4J library|http://www.icu-project.org/]; there might be other implementations out there, so we should leave the option open to swap for another one.

See http://en.wikipedia.org/wiki/Unicode_equivalence#Normal_forms for background information.

was:
In light of MGNLWEBDAV-15, we need Magnolia to be a little more lax with unicode names.

There are two sides to this issue:
* the current {{SimpleUrlPattern}} implementation chokes on paths with unicode characters in the decomposed form.
* Jackrabbit does no unicode normalization for node names, thus a node created with a name in the composed form can not be retrieved by using the decomposed form of the exact same name.

Since "clients" tend to use one or the other form arbitrarily (Firefox 3.0 on MacOSX sends GET parameters in the NFD form, Safari in NFC; while the Linux OS tends to favor NFC and OSX tends to favor NFD, for insance).

Node name normalization unfortunately requires using either Java 6 ([{{java.text.Normalizer}}|http://java.sun.com/javase/6/docs/api/java/text/Normalizer.html]), the [ICU4J library|http://www.icu-project.org/]; there might be other implementations out there, so we should leave the option open to swap for another one.

See http://en.wikipedia.org/wiki/Unicode_equivalence#Normal_forms for background information.

> Enhance unicode support
> -----------------------
>
> Key: MAGNOLIA-2929
> URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2929
> Project: Magnolia
> Issue Type: Improvement
> Components: core
> Reporter: Grégory Joseph
> Assignee: Grégory Joseph
> Fix For: 4.2
>
>
> In light of MGNLWEBDAV-15, we need Magnolia to be a little more lax with unicode names.
> There are two sides to this issue:
> * the current {{SimpleUrlPattern}} implementation chokes on paths with unicode characters in the decomposed form.
> * Jackrabbit does no unicode normalization for node names, thus a node created with a name in the composed form can not be retrieved by using the decomposed form of the exact same name.
> Since "clients" tend to use one or the other form arbitrarily (Firefox 3.0 on MacOSX sends GET parameters in the NFD form, Safari in NFC; while the Linux OS tends to favor NFC and OSX tends to favor NFD, for instance).
> Node name normalization unfortunately requires using either Java 6 ([{{java.text.Normalizer}}|http://java.sun.com/javase/6/docs/api/java/text/Normalizer.html]), the [ICU4J library|http://www.icu-project.org/]; there might be other implementations out there, so we should leave the option open to swap for another one.
> See http://en.wikipedia.org/wiki/Unicode_equivalence#Normal_forms for background information.

[JIRA] Commented: (MAGNOLIA-2756) Cleanup namespaces in some of our bootstrap files

2009-11-05T12:22:37Z

[ http://jira.magnolia-cms.com/browse/MAGNOLIA-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=24756#action_24756 ]

Hudson CI server commented on MAGNOLIA-2756:
--------------------------------------------

Integrated in !http://hudson.magnolia-cms.com/nocacheImages/16x16/blue.gif! [standard-templating-kit #2128|http://hudson.magnolia-cms.com/job/standard-templating-kit/2128/]
: removed bad namespaces and set activation flag accordingly

> Cleanup namespaces in some of our bootstrap files
> -------------------------------------------------
>
> Key: MAGNOLIA-2756
> URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2756
> Project: Magnolia
> Issue Type: Bug
> Components: cache, core
> Affects Versions: 4.1
> Reporter: Grégory Joseph
> Assignee: Grégory Joseph
> Priority: Critical
> Fix For: 4.1
>
>
> For instance, when exporting a file, we now have namespaces such as
> - {{xmlns:jcrutils="xalan://it.openmindonline.urmetdomus.assembler.utils.Path"}} ?
> - {{xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882"}} ??
> - {{xmlns:stringutils="xalan://org.apache.commons.lang.StringUtils"}} StringUtils????
> and other just-as-suspicious ones, such as {{xmlns:x="urn:schemas-microsoft-com:office:excel"}}.
> h3. Findings:
> Jackrabbit has a centralized namespaces registry. It stores/caches the registered namespaces under {{repositories/magnolia/repository/namespaces/ns_idx.properties}} and {{repositories/magnolia/repository/namespaces/ns_reg.properties}}
> When you start with a clean repo, it only has very basic NSs (jackrabbit, jcr, mgnl). As soon as you bootstrap one of the "infected" files, however, the "suspicious" NSs from that file are registered. Subsequently, any node that you will export from this repository will result in an exported file with these namespaces. That's why I used the word "infected" - because as soon as one has bootstrapped such a weird file, your system is basically "infected".
> This was probably introduced by accident in ONE file (namely one bootstrap file of the cache, which is the first to register these NSs when installing a fresh instance) and subsequently spread to all the others.
> The oldest revision I can find that introduced (some of) these namespaces is {{r24820}} for {{magnolia-module-cache/src/main/resources/mgnl-bootstrap/cache/config.modules.cache.config.configurations.default.xml}} (MAGNOLIA-2616)
> How or why these were introduced at that point is still a mystery (maybe a buggy Jackrabbit was used when this file was exported, or the file was tempered upon using some misbehaving tool)
> To avoid having to start from a clean repo, I *think* (to be double-checked) that simply removing the ns_idx.properties and ns_reg.properties files could work.

Hudson build is back to stable: magnolia_main-trunk #1080

2009-11-05T10:36:35Z

See <http://hudson.magnolia-cms.com/job/magnolia_main-trunk/1080/>

----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
----------------------------------------------------------------

Hudson build is back to stable: magnolia_main-trunk » magnolia-module-exchange-simple #1080

2009-11-05T10:36:33Z

See <http://hudson.magnolia-cms.com/job/magnolia_main-trunk/info.magnolia$magnolia-module-exchange-simple/1080/>

----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
----------------------------------------------------------------

[JIRA] Commented: (MAGNOLIA-2929) Enhance unicode support

2009-11-05T10:27:36Z

[ http://jira.magnolia-cms.com/browse/MAGNOLIA-2929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=24754#action_24754 ]

Hudson CI server commented on MAGNOLIA-2929:
--------------------------------------------

Integrated in !http://hudson.magnolia-cms.com/nocacheImages/16x16/yellow.gif! [magnolia_main-trunk #1079|http://hudson.magnolia-cms.com/job/magnolia_main-trunk/1079/]
Added \p{Mn} to the list of allowed characters so that unicode paths in the decomposed form don't trigger irrelevant AccessDeniedException

> Enhance unicode support
> -----------------------
>
> Key: MAGNOLIA-2929
> URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2929
> Project: Magnolia
> Issue Type: Improvement
> Components: core
> Reporter: Grégory Joseph
> Assignee: Grégory Joseph
> Fix For: 4.2
>
>
> In light of MGNLWEBDAV-15, we need Magnolia to be a little more lax with unicode names.
> There are two sides to this issue:
> * the current {{SimpleUrlPattern}} implementation chokes on paths with unicode characters in the decomposed form.
> * Jackrabbit does no unicode normalization for node names, thus a node created with a name in the composed form can not be retrieved by using the decomposed form of the exact same name.
> Since "clients" tend to use one or the other form arbitrarily (Firefox 3.0 on MacOSX sends GET parameters in the NFD form, Safari in NFC; while the Linux OS tends to favor NFC and OSX tends to favor NFD, for insance).
> Node name normalization unfortunately requires using either Java 6 ([{{java.text.Normalizer}}|http://java.sun.com/javase/6/docs/api/java/text/Normalizer.html]), the [ICU4J library|http://www.icu-project.org/]; there might be other implementations out there, so we should leave the option open to swap for another one.
> See http://en.wikipedia.org/wiki/Unicode_equivalence#Normal_forms for background information.

Hudson build became unstable: magnolia_main-trunk #1079

2009-11-05T10:26:52Z

See <http://hudson.magnolia-cms.com/job/magnolia_main-trunk/1079/changes>

----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
----------------------------------------------------------------

Hudson build became unstable: magnolia_main-trunk » magnolia-module-exchange-simple #1079

2009-11-05T10:26:50Z

See <http://hudson.magnolia-cms.com/job/magnolia_main-trunk/info.magnolia$magnolia-module-exchange-simple/1079/>

----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
----------------------------------------------------------------

[JIRA] Commented: (MAGNOLIA-2929) Enhance unicode support

2009-11-05T10:18:36Z

[ http://jira.magnolia-cms.com/browse/MAGNOLIA-2929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=24753#action_24753 ]

Hudson CI server commented on MAGNOLIA-2929:
--------------------------------------------

Integrated in !http://hudson.magnolia-cms.com/nocacheImages/16x16/blue.gif! [magnolia_main-trunk #1078|http://hudson.magnolia-cms.com/job/magnolia_main-trunk/1078/]
Added default implementation for UnicodeNormalizer$Normalizer in mgnl-beans.properties

> Enhance unicode support
> -----------------------
>
> Key: MAGNOLIA-2929
> URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2929
> Project: Magnolia
> Issue Type: Improvement
> Components: core
> Reporter: Grégory Joseph
> Assignee: Grégory Joseph
> Fix For: 4.2
>
>
> In light of MGNLWEBDAV-15, we need Magnolia to be a little more lax with unicode names.
> There are two sides to this issue:
> * the current {{SimpleUrlPattern}} implementation chokes on paths with unicode characters in the decomposed form.
> * Jackrabbit does no unicode normalization for node names, thus a node created with a name in the composed form can not be retrieved by using the decomposed form of the exact same name.
> Since "clients" tend to use one or the other form arbitrarily (Firefox 3.0 on MacOSX sends GET parameters in the NFD form, Safari in NFC; while the Linux OS tends to favor NFC and OSX tends to favor NFD, for insance).
> Node name normalization unfortunately requires using either Java 6 ([{{java.text.Normalizer}}|http://java.sun.com/javase/6/docs/api/java/text/Normalizer.html]), the [ICU4J library|http://www.icu-project.org/]; there might be other implementations out there, so we should leave the option open to swap for another one.
> See http://en.wikipedia.org/wiki/Unicode_equivalence#Normal_forms for background information.

[JIRA] Commented: (MAGNOLIA-2929) Enhance unicode support

2009-11-05T10:11:37Z

[ http://jira.magnolia-cms.com/browse/MAGNOLIA-2929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=24752#action_24752 ]

Hudson CI server commented on MAGNOLIA-2929:
--------------------------------------------

Integrated in !http://hudson.magnolia-cms.com/nocacheImages/16x16/blue.gif! [magnolia_main-trunk #1077|http://hudson.magnolia-cms.com/job/magnolia_main-trunk/1077/]
introducing a wrapper/helper for unicode normalization

> Enhance unicode support
> -----------------------
>
> Key: MAGNOLIA-2929
> URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2929
> Project: Magnolia
> Issue Type: Improvement
> Components: core
> Reporter: Grégory Joseph
> Assignee: Grégory Joseph
> Fix For: 4.2
>
>
> In light of MGNLWEBDAV-15, we need Magnolia to be a little more lax with unicode names.
> There are two sides to this issue:
> * the current {{SimpleUrlPattern}} implementation chokes on paths with unicode characters in the decomposed form.
> * Jackrabbit does no unicode normalization for node names, thus a node created with a name in the composed form can not be retrieved by using the decomposed form of the exact same name.
> Since "clients" tend to use one or the other form arbitrarily (Firefox 3.0 on MacOSX sends GET parameters in the NFD form, Safari in NFC; while the Linux OS tends to favor NFC and OSX tends to favor NFD, for insance).
> Node name normalization unfortunately requires using either Java 6 ([{{java.text.Normalizer}}|http://java.sun.com/javase/6/docs/api/java/text/Normalizer.html]), the [ICU4J library|http://www.icu-project.org/]; there might be other implementations out there, so we should leave the option open to swap for another one.
> See http://en.wikipedia.org/wiki/Unicode_equivalence#Normal_forms for background information.