Hi all,
$subject was started focusing following issues with the old implementation.
- Ease of maintainability in the long run
- All the core functions were separated into groups called modules.
- Error messages and site configs were separated into *.json configs.
- URL mappings were also used in order to offer the option to
customize them as we wanted.
- Exposing of the site content through SOAP/REST/JSON services
without affecting the sites functionality
- Ability to customize the theme easily
- Site content was grouped into something called blocks and pages
were built using those blocks where blocks can be reused and
themed separately.
- Multiple themes can be used onces and change depending on user
preference(this is optional)
- Separation of content into smaller modules in order to improve the
performance under a high traffic
- One can require a module using a util method and use
that functionality. So, only the needed *.jag files will be loaded and
executed. Earlier we were loading every function into the memory.
- Identify Jaggery improvements when a complex web app is built and a
better model for Jaggery apps
- Need for several things in Jaggery were also identified such as
need of an application context, require_once, ability to require *.json
configs
- Further, the idea of using the new model/experience as a foundation
for a Jaggery based drupal/joomla like framework
The new implementation has already covered most of the above tasks. As it
was done through several iterations, there are still
missing functionality that need to be added in to the new UIs. So a new
milestone build will triggered by Monday with this new implementations.
Thanks,
Ruchira
--
Ruchira Wageesha
Software Engineer - WSO2 Inc. www.wso2.com
Email: [email protected] Blog: [email protected]
Mobile: +94775493444
Lean . Enterprise . Middleware
_______________________________________________
Dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/dev
