Dashboard > Magnolia Development > ... > Backlog > Backlog Pool Of New Items
Backlog Pool Of New Items Log In View a printable version of the current page.

Added by Grégory Joseph , last edited by Grégory Joseph on Nov 13, 2008  (view change)
Labels: 
(None)

  • I18N content support: make it a module; provide more sophisticated implementations than the current DefaultI18nContentSupport one (that uses URI prefixes).
    Idea: implement a chain that tries to determine the locale as follows:
    1. URI
    2. cookie
    3. IP address range
    4. browser locale

work already started with the enterprise i18n module

  • Filters checking. Currently it is possible to start up magnolia even if some filters in the chain fail to initialize. This allows user to fix whatever is broken as long as system can at least partially function, on the other hand it possibly introduces point of unsecurity (if security filter fails, instance will be running but unsafe) ... we need to review this and decide whether some filters will be mandatory or not and what class/part of the system will be responsible for such checking. 

Please move contents here

(see attachments in parent page)

New items

  • Standalone bundle: See if Magnolia could be deployed in Winstone - if so, we could possibly provide a "standalone" application instead of the Tomcat bundle. We could get inspiration from Hudson, since they do that too. Magnolia could be launched with java -jar magnolia.war, and thus could be double-clicked. We can already imagine a minimal gui (falling back to console input or command line parameters if no screen is available) that would ask the user for a port number, contextPath and if the instance is an author or a public. This would then bootstrap and start Magnolia within Winstone. The concept of the 2 instances authoring vs publication would possibly become more obvious and understood by new users, compared to the single tomcat running the 2 webapps.
  • Consider using Google Gears: currently, our cache configuration is fairly complex, and one of the reasons is that we use the Magnolia cache mechanism to cache author environment resources. This was introduced in 3.6 and sped up things dramatically but also complexified the configuration. Using Gears might alleviate this problem, along with help more transparent updates, since it is version-aware. (cached resources can be versioned and updated when necessary)

One more great thing. "Media Edition" will be (or could be?) JSP free, which in turn means we can create a version that requires no java compiler on the client. In other words, we are even closer to the goal of providing newbies an easy entry path to Magnolia. that is really cool

In terms of samples, we'll probably still need to provide a minimal set of jsp samples, but when not using jsp, a JRE should indeed be sufficient. Note that even with jsp, Tomcat (some semi recent release, maybe already 5.5) is configurable to use the JDT (eclipse) compiler, and should thus work with a jre as well.

where is the i18n module linked to above?

just fixed svn url

Powered by a free Atlassian Confluence Open Source Project License granted to Magnolia International. Evaluate Confluence today.
Powered by Atlassian Confluence 2.7, the Enterprise Wiki. Bug/feature request - Atlassian news - Contact administrators