Regarding modules and workspace structure

[vlad-ghita]

Couldn't find a better place to discuss about this (comments can't be placed in WIKI pages).

I'm totally in for the modules idea. I noticed your hard work lately and congrats for the results.

I was thinking about the whole modules concept and I can't help myself looking at how Symfony does it with it's bundles or Drupal with their modules. Mainly, I was wondering if it actually is a good idea to keep all resources from modules and site-dependent stuff in same folders in workspace. Given this:

A complete module as described above can be picked up and inserted in another Symphony site without all too much configuration/customization. Modules are generic and can be shared between the community.

how is a module supposed to be installed? Take a News module which provides the whole range of resources: Sections, Pages, DSs, Events, other XSLT utilities, styles and libraries. Wouldn't it be a good idea to keep everything self-contained? eg:

/news
    /assets
        /libraries
        /styles
    /data-sources
    /events
    /pages
    /sections
    /utilities

Going down on this road, I'm starting to look at how extensions and modules are quite similar. In the end, a module is just another extension, right?

ATM Symphony auto-discovers DSs and Events provided by an extension. Let's extend that to Sections and Pages. utilities and assets can be copied by Symphony on installation to custom, developer defined folders from admin; eg:

/extensions/module_news/utilities/* --> /workspace/__developerDefinedPathForUtilitiesHere__/module_news/*
/extensions/module_news/assets/styles/* --> /workspace/__developerDefinedPathForStylesHere__/module_news/*
/extensions/module_news/assets/libraries/* --> /workspace/__developerDefinedPathForLibrariesHere__/module_news/*

/cc @brendo, @nickdunn

[brendo]

Going down on this road, I'm starting to look at how extensions and modules are quite similar. In the end, a module is just another extension, right?

Yes, that was my concern. I don't feel we need to introduce modules when they are essentially extensions. The main difference (from memory, and it's still not solved) is that if an extension provides a section, should this be read only? It follows the convention set by events and datasources, but it makes it limiting to users. That said, if a user changes the section and the extension developer releases an update it may be difficult to manage what happens next. Does the user's section get overridden? The extension fail to update? The section try to merge both?

I still believe the best way forward is for extensions to be expanded to allow for /sections and /pages folders.

[kanduvisla]

I also havo some thoughts on what's the best way to implement this, but the first priority is to make Symphony behave exactly the same with external files as it does now the database-way. That traject is almost finished now (beer time !!!), and it's good to start thinking about what should be the best way to implement this in a workflow.

As mentioned there are a lot of things to consider: should modules be read-only? Should paths be adjusted? Etc. it's good to share some different visions in this thread, to share ideas and come up with a concept for this.

So, share your ideas and thoughts on this, and let's work together on how to implement this gem. (also, 'Modules' is kind of a quirky name and I consider it a working title, so if you got a cool catchy name for this cocnept, that's welcome too!)

[Gaya]

Just discussed this with Giel and I am looking forward to seeing this happen in Symphony CMS. What he showed me looks very promising and I am going to Unit Test the living sh- out of it in a few minutes. But I wanted to give my two cents on this topic first.

So, what I think is important (for the future) is to have modules stored in folders and ready for a simple copy/paste action. The thing is that I don't see these modules as extensions since they give a lot more to work on. The goal is to get something like a "news" module and copy it to another website. This will contain it's pages, data-sources, sections and utilities. I don't really think it's important to include styles and libs for now, that would indeed begin to look a lot more like extensions.

I see modules as basic packages for you to use with your own xsl pages and making it easy to add certain content blocks in your own pages. The pages that can be copied through this modules approach will already contain this code of course.

I think stuff should be put in a /modules/ folder. It can be stored in either /workspace/ or in the root. That doesn't really matter.

Great work!

[vlad-ghita]

The main difference (from memory, and it's still not solved) is that if an extension provides a section, should this be read only? It follows the convention set by events and datasources, but it makes it limiting to users. That said, if a user changes the section and the extension developer releases an update it may be difficult to manage what happens next. Does the user's section get overridden? The extension fail to update? The section try to merge both?

If I install a news module containing the News section and I want to modify it in current site, I want to be able to do so.

If there is an update to News module, better no merging than sorry.

[kanduvisla]

The word 'Modules' is actually misleading. 'XML Based Storage' would be better.

The idea is that sections and such are no longer stored in the database but in XML-files, allowing them to be copy-pasted into other sites. The whole fact that this could work as a 'Module' is a nice extra.

The way I see it, something like this doesn't have to be placed outside the workspace-folder, because that's where all the sites' assets are stored. Putting external/downloaded sections outside the workspace-folder would be the same as placing external/downloaded XSL-utilities outside the workspace-folder, which doesn't make sense.

So in short: Don't see this as 'extensions', but just a whole approach to the saving of sections.