@Lauri, thanks for opening DOCU-280 "Best practice: developing with magnolia". The question of best practices is very broad. A lot depends on the size of your organization, as Richard pointed out, and on how far along you are in learning Magnolia. Here are some links on the topics you mention.
"IDE setup" * The dev environment setup takes you through the process with Eclipse on Windows http://documentation.magnolia-cms.com/developing/dev-environment.html * The Eclipse page on the wiki has more details http://wiki.magnolia-cms.com/display/DEV/Eclipse * Intellij IDEA is also popular http://wiki.magnolia-cms.com/display/DEV/Intellij+IDEA * Search the wiki for Netbeans. There are couple of pages that may help you that IDE. If not, the pages could use an update. :) "Bundled or mavenized" I am not the best person to answer this question but I will take a stab. The Magnolia bundle is a good place to start exploring Magnolia. It contains the basic two-instance setup: author and public. You can start it up and learn how Magnolia works. I'm sure there are developers who work with the bundle even beyond learning and into production use. However, the bundle may not be the best practice if you are looking for flexibility and reproducibility. With Maven you can pick and choose which parts of Magnolia you actually need. Maybe the Enterprise bundle has modules that you don't need? (It is missing your custom modules for sure.) With Maven you can choose what to exclude and include. This might make your WAR file smaller too. With Maven you have the same build everywhere. You *know* what's in production, and can rely on the tools to reproduce the same binaries if you need them. "JSP vs Freemarker" Both work. Rather than pit just the two, ask which templating language you want to use. Other languages can be supported. Freemarker has some advantages such as the ability store scripts in the Magnolia repository and edit them inside the Magnolia UI. Freemarker is used more in the core product just because we know it better. I cannot name a use case where one would be clearly better than the other. "Module or WAR" I will rephrase this as "bundle plus manually deploy a module" or "deploy a WAR that already contains my module". There is a series of blog posts by Gregory where he advocates the second approach. Deploying a single WAR file makes the administrator's life easier. Regardless of the target environment (dev, test, prod) the admin deploys the same file. The WAR also packages the whole project into a single entity, which allows you to keep track of dependencies. You have confidence that the libraries you have in your development environment are the same as those used in production. Sure, it may be faster to deploy just your custom module JAR file into production but then you introduce some uncertainty whether the right versions of dependent components are also present in the target environment. http://dev.magnolia-cms.com/~gjoseph/dont-build-magnolia-build-your-projects http://dev.magnolia-cms.com/~gjoseph/dont-configure-magnolia-let-your-projects-configure-it http://dev.magnolia-cms.com/~gjoseph/dont-deploy-magnolia-deploy-your-project "Blossom vs. bootstrap" This is a question of where you should define your templates, components and dialogs. You can define them in configuration (bootstrap files) or create them dynamically with the Blossom module. Again, there is no single best practice. The bootstrap file mechanism is crude, mechanic and perhaps a little labor intensive but it is transparent to everyone involved. You define a dialog configuration in AdminCentral, export the config into XML, include the XML in your bootstrap files, and configure a version handler to deploy the changes during install and update. The resulting configuration is visible in AdminCentral. Administrators can change it on-the-spot, albeit looping the change back into version control takes some effort. Creating configuration dynamically with Blossom means you can populate the dialog at runtime. Dialogs are not stored in the repository but are in the code. This means that they are automatically in your version control but they are not visible to admins. A use case that calls for the dynamic approach is a site where you need to create different templates, components or dialogs based on conditions detected at runtime. There's also the possibility to create the definitions using code in the module version handlers. While it can quickly become hairy, with some factorization and using an API like nodebuilder you get the advantage that they are all in the same place, and that they can be updated/migrated between versions from the same place too. --Antti -- Context is everything: http://forum.magnolia-cms.com/forum/thread.html?threadId=69ea1310-8a60-4f43-a32d-ad8d6d62511f ---------------------------------------------------------------- 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]> ----------------------------------------------------------------
