Hi Richard, first thanks for the detailed feedback. And also few comments of my own to it
[quote]Anything except JCR has significant disadvantages when it comes to a real world production setup.[/quote] Not true. I agree that there is setup and work practice for which JCR works best and that's the one we used to recommend before introducing LD. While designing LD we have discovered other working patterns that we believe are more agile and even more beneficial than JCR, addressing number of other pain points that we were trying to solve for years. It might not be that everyone suffered from such issues or that they were not major enough, however we do not want to stop innovating the framework just because some users were already satisfied with it as it was. [quote]Since FS or classpath resources can't be activated, deploying templates stored in those locations is a major pain, requiring physical copying to each public node, and a server restart (unless you have your production server in development mode, then in theory it could hot-load FS resources. Classpath always needs a restart). So in community edition you would have actual downtime to deploy templates (only one public node), while in enterprise edition you could theoretically do a complex rolling deploy over several public nodes to prevent downtime, but you'd lose the transactional activation that guarantees consistency, and be serving different versions of the page during the deploy. It's also very hard to coordinate the deployment of content and resources when the resources aren't in JCR. [/quote] Again, not true. What you describe applies for classpath resources, but not to those that are on the FS and brought in via Light Modules. I don't know where this misconception is coming from and it would be interesting for me if you would be willing to elaborate on what made you think this is true for Light Modules. In light modules, and I have few projects using those, you can change your definitions or template scripts or other resources such as css or js and have them picked up by server, in production, without restart. It's actually even better. It's picked up by all author and all public instances at once with single step. My setup and workflow is as follows: - resources directory of Magnolia is configured outside of the webapp - all light modules are in git - I work on the branch, and only after testing the code locally, merge any and all my code changes to master - git repo is cloned in the resources directory of Magnolia on each server - servers are configured to observe git and pull in all changes from remote master when they occur with polling interval set to 5 seconds No need for activation, no need for remote access to the system and yet I'm able to modify all files in my favorite tools and have full version control and audit log of who did what. How much better can it get? This is more than I was ever getting from JCR and as long as I have access to git repo, I can do update from any place and any device (yeah, done this from the phone too, which is much more comfortable for working with github than with the internal code editor in Magnolia). Where in this scenario am I missing anything that activation over JCR was offering to me? [quote]Armasescu's question is perfectly legitimate. Why can't JCR resources be renamed? It's obvously a necessary feature for those of us using JCR.[/quote] Indeed this is legitimate question. No dispute here. And the answer is: it can be. But you need to use processed resources app. If you want to use JCR resources exclusively this is the app to use. If you want to work with Light Modules, Magnolia instance is a terminal node for distribution of the files/code in those modules. Hence no renaming functionality. It is not meant to be. If you want to rename the resource, rename it in your local clone of the light module, commit it to the repository and get the change distributed to all of your servers. [quote]Magnolia has caused a slew of problems in terms of usability, bugs and security issues by releasing the new resources concept without properly analyzing the impact beforehand. The new system is broken by (lack of) design.[/quote] I respectfully disagree. You were not part of internal process and have no clue whether and what we analyzed and not. Please do not jump to conclusions. We did analyze the benefits and costs of introduction of light development and decided that benefits outweigh the costs. Success of the feature confirms this analysis. Yes, there are those who were satisfied with the way how working with resources and publishing of them via JCR worked previously but that is not reason to stop the development and evolution of the product. We tried to make it as little disruptive as possible for you to continue using old ways should that be your preferred way of working with Magnolia. However do not claim that we didn't know what we are doing just because you didn't grow to like new working pattern. [quote]It was all "yay, light development, let's go", and the new resources concept is therefore missing essential functions like the renaming in JCR that Armasescu has noticed, but also the following: - no activation of non-JCR resources[/quote] Not true. You can activate JCR resources via processed resources app same as before. Should you edit FS or Classpath based resource over JCR, you can activate such change as well. Previously you could NOT see and amend CP based resource w/o knowing exactly what path it lies on and recreating that manually. Now we made this much more transparent. How is that not an improvement? [quote]- no processed resources[/quote] Again, you can install and use processed resources app should you require so. We don't do this ootb and do not recommend it as best working pattern. Why? Because there are plenty of tools that can do pre-processing of resources much more efficiently than Magnolia itself. And more of it. You can do all minification, sass/less translation, combining js scripts, creating image sprites and much more. Why would we limit you to do just few of those within Magnolia when you can do it all outside and bring it to productive servers at runtime all the same? There are few corner cases where you want to inject something from within Magnolia, but that's something that 90% of users don't need, hence we still support it via processed resources app, but do not install by default and do not encourage anyone to go down that path as we see it limiting flexibility of development in long term. [quote]- resources can no longer have models or templates to render them[/quote] Sure they can, via processed resources or via custom apps or custom pages/components/renderers. Yet again, while preprocessing is common and can be done more efficiently outside of Magnolia and brought to production by means described above, templating/processing at runtime is much less often necessary. Similarly for working with models, we recommend working with templating functions and in templates directly these days since it requires less distinct sets of experience for the users. Yet still should you want to work with models you can and there are certainly the cases when it's necessary. [quote]- major security problem where your entire classpath gets exposed to the internet (apparently fixed in 5.5) - major bug with stale JCR Node references (now fixed, I think) JCR and the fact that magnolia *can* deploy resources via activation are major strengths of your CMS. FS and particularity yaml are cool for developers, but in the end running the sites is as important as developing them, in my opinion.[/quote] In your opinion. Indeed. The results we are seeing overall and research we have been making suggest otherwise. For majority of our users the light modules and possibility of accessing resources on FS directly without CMS interrupting in between is a major advantage. And as I said, even with that we still support old ways of development for existing projects created before introduction of LD or for those for whom old ways were "perfect" and do not need or wish for anything more. But just because you don't want to use it, doesn't mean it is bad or failure in general. [quote]JCR is more than just a solution to "patch" resources. There is no reason at all the new resources concept can't work well with JCR, it just needs a bit more thought and work to complete the new resources app. I would suggest thinking about the following: - add back the ability to properly work with JCR resources: move, rename, etc... - add back the processed resources. See my scss-resources-module for an idea of how this could work - add the ability to activate FS resources. This would give the best of both worlds: GS development and activation for production [/quote] Again, it is well thought. In new process CMS receives templates and definitions defined outside of it. They are manipulated in any and all ways outside, hence no need for doing anything inside of CMS except for patching for which we decided to use JCR. Similarly all processing of templates such as sass translation can happen much more easily and fluently outside with light modules and for example gulp or grunt tools. Using and connecting code repository for the code allows you to distribute the code to all necessary locations via pull mechanism making it much more flexible and resilient to failure. We understand that this pattern takes a bit of thinking before understanding and adopting. however we are strongly convinced that it is worth the effort. Results we are seeing and responses we are getting are all confirming this approach. Yet we also understand that it is not for everyone. That's one of the real strengths of Magnolia - you can extend it to your liking. If you like to have all templates and configurations in JCR, you can and you can use processed resources app to manipulate and execute them. Similarly there are other parts of community that like to define all their templates and definitions via spring. Those too can do it by simply installing blossom module. There is no discrimination, we have just chosen default which we believe is most progressive and provides most benefits to biggest part of the community that's all. Cheers, Jan -- Context is everything: http://forum.magnolia-cms.com/forum/thread.html?threadId=664d58e1-ec19-4cbe-b918-19bc44116774 ---------------------------------------------------------------- For list details, see http://www.magnolia-cms.com/community/mailing-lists.html Alternatively, use our forums: http://forum.magnolia-cms.com/ To unsubscribe, E-mail to: <[email protected]> ----------------------------------------------------------------
