Module support

[Brett]

Quick question - does ColdMVC have any support for modules? It
appears to me that it only supports the single app directory, but
wasn't sure if there was something under the hood I am missing.

thanks,

.brett

[Tony Nelson]

Modules have been the #1 thing on my to-do list for quite awhile. I haven't began development on them yet since I'm not quite sure how they should work yet, especially in comparison to the newly added plugin support.

Ideally modules should almost act as stand-alone sub-applications, similar to subsystems in Framework 1. However, I'm not sure how those sub-applications should be defined (config? convention based sub-directories?), where their components should live (multiple bean factories? parent/child bean factories?), how their routes are defined, how interceptors should work, etc...

I've also been on the fence about adding more code to the core framework, or just building out better support for plugins and adding modules as a core plugin. I really want to keep ColdMVC as simple as I can, but maybe you could justify modules as an essential part of the framework.

Do you have any thoughts on how modules should work?

-Tony

[Dan Vega]

I am really torn on this one. I originally brought this up to Tony but
the more and more I think about it the more I don't like it. I would
love to hear some other examples from people because the classic one I
can think of is the admin/client example. You basically have 2
applications, an admin app to manage the data and a client app to
display the data. You could always just run setup some filters for the
methods like create/save/delete to make sure the user is authenticated
before running those methods.

Again this is one of those things that I have looked across many
languages and many frameworks and there is no "right' answer. I would
love to hear what everyone else thinks about it.

[Brett]

Hey guys,

Yeah the main difference I see is that plugins are global to the app,
where as modules live in their own container or scope. Many modules
may use the same controller name and these need to be distinguished
from one another and at the very least routes configs would also be
specific to the module too. Ideally the implementation would be
cascading (coldMVC does a good job of this now). Module > Plugins >
ColdMVC. w/ configurable conventions.

I think the biggest advantage I see is the ability to group many
different applications under the same ColdMVC scope. Right now these
all live in separate applications so everything has to be wired
independently.

What I am really after is support for sub requests. Modules would get
me closer because they would allow applications to be loaded into
their own scopes and not interfere with each other. This would allow
me to call multiple modules in a single request and not be bound to a
HTTP request. Kinda like Zends dispatch loop.

In our framework, we have a master layout with many containers. In
each of the containers any number of modules can be included, so to
process a page request we loop through all the modules in the
container and execute each module. An example of this might be a page
with a HTML WYSIWYG module on top of a Photo Slideshow module. I'm
not sure how to do that with ColdMVC without coding the HTMLs and
slideshows as plugins, making sure to use distinct names for all of
the beans and I am not even sure that would work.

thoughts? Is there another way to do this?

.brett

[Tony Nelson]

I really like the concept of modules and I'd really like ColdMVC to be able to support them, but again we just need to iron out the details first.

My primary concerns revolve around memory and where the modules are stored. Right now plugins all live within the same application scope as your main application in order to be able to autowire everything together seemlessly. With modules, I would expect them to live outside of the main application scope (or at least outside of the main application's bean factory) in order to avoid conflicts between bean names, routes, config settings, etc.... However, if they live outside of the main application, what effect does that have on autowiring, ORM, caching, interceptors, helpers, etc... Basically how do modules interact with global components?

Aside from the admin/client modules that Dan mentioned, I think other examples would be your typical CMS module, blogging module, wiki module, forum module, shopping cart module, etc. Obviously you could attempt to create them all as plugins, but that comes with drawbacks. Each one is going to need a User entity, but where does that entity live? Same goes for security. You'd really like those areas of your application to be able to live separately from your main application in order to avoid conflicts, yet still able to integrate together in a nice way.

Maybe instead of just having a single bean factory (located at coldmvc.application.beanFactory), have multiple bean factories (coldmvc.application.beanFactories[module])? Then have something like #linkTo({module="admin", controller="user", action="list"})# or #linkTo({controller="/user", action="list"})# with a forward slash (/) to return to the base application?

I really want to open up all the possibility for modules, since they could be really powerful. Thoughts?

-Tony

[Joe]

I kinda like Brett's idea of separating modules and plugins. I am
interested in the module support, where the modules live inside of
your own app with their own scopes. I decided to take a stab at how
that this could play out "theoretically". I took the name space
approach, that Brett brought up in another thread, by prefixing
everything with the name of the module. I am going to treat the
app.cfc in main dir as the global application.

Here's where I would put the modules in dir structure.
myapp
->app
-->modules

First I define my modules and where they are in the dir myapp->config-
>modules.xml.
Example:
<module name="CMS" path="modules/cms"/>
<module name="Security" path="modules/security_management"/>

Next ColdMVC would prefix all the beans within the CMS and Security
modules with the prefix.
Example: CMS_Site, Security_SecurityService

How helpers might look.
Examples:
myapp helper = $.form.input()
cms module helper = $.cms.site.getCurrentSite()
security module helpers = $.security.permissions.edit()

How routes might play out.
<cfset add("/go/:module/:folder", {
defaults = {
controller="route",
action="render"
},
modules = ["cms"]
})/>

I am just prefixing all modules with a unique name.

Last night, I setup a test case where I ?init a parent or global
app.cfc and tried to ?init the app.cfc's in the subdirectories.
Couldn't figure out.

I am I just "out there" on this idea or does this sound do-able?

[Tony Nelson]

It's a good idea, however I think modules should be unaware of the fact that they're modules (if that makes sense). If I have a Wiki module, it should be able to function as it wants without having to prefix its components, meaning it should be able to have a UserController, rather than a WikiUserController. I have a couple thoughts on how this could work out using multiple bean factories, which essentially creates multiple application scope containers. I'll try to get my thoughts together this weekend and share them when I can.


-Tony

[Brett]

I think Joe is suggesting that ColdMVC does the prefixing rather than
having the developer do it, so it remains transparent. If I'm
currently executing the Wiki module, ColdMVC would take care of
applying the prefix to all requested Beans. Possibly first checking
for an existing module namespaced bean, then if one is not found,
looking for a bean of the same name without the prefix. This would
allow for them to be cascaded.

I'm not sure this would be as clean as what you are thinking though
Tony. But this was the direction I was going to "hack" in support
before I brought up the question to the group.

.brett

On Jun 11, 11:14 am, Tony Nelson <tonynelso...@gmail.com> wrote:
> It's a good idea, however I think modules should be unaware of the fact that
> they're modules (if that makes sense). If I have a Wiki module, it should be
> able to function as it wants without having to prefix its components,
> meaning it should be able to have a UserController, rather than a
> WikiUserController. I have a couple thoughts on how this could work out
> using multiple bean factories, which essentially creates multiple
> application scope containers. I'll try to get my thoughts together this
> weekend and share them when I can.
>
> -Tony
>

[Tony Nelson]

Yeah it could possibly work with ColdMVC transparently adding the prefix to the beans, however I think that might cause problems and confusion when it comes to autowiring, among other things. I think it might be cleaner to segment multiple bean factories with support for a module/core bean factory hierarchy rather than trying to segment individual beans inside a single factory, although having a single factory might make interceptors, helpers, tags, and routes a little easier to deal with.

-Tony

[Tony Nelson]

After working with Zend more, I think I have a better idea of how modules could work inside ColdMVC.

You would be able to define controllers, layouts, and views within modules. Basically the things that you'd want to somewhat separate on per-request basis.

Controllers would not be defined within the bean factory, but managed internally inside a ControllerFactory. This should allow us to avoid naming conflicts. Rather than ColdMVC calling beanFactory.getBean("userController"), it would call beanFactory.getBean("controllerFactory").getController("userController" [, module]).

Since there is only 1 ORM context per application, you would place your models within the main /app/models. This is kind of how we do with Doctrine and Zend and it seems to work pretty well.

Helpers, tags, and config settings would also be defined within the main application in order to avoid possible naming conflicts between modules.

Here's what a typical directory structure might look like:

/app
    /controllers
    /helpers
    /layouts
    /models
    /modules
        /bar
            /controllers
            /layouts
            /views
        /foo
            /controllers
            /layouts
            /views
    /tags
    /views
/config
/public

What do you guys think? Is this worth pursuing?

[Tony Nelson]

I decided to go ahead and stub in support for modules in version 1.5.0
of ColdMVC.

I tried to be extremely careful to maintain backwards compatibility,
and for the most part all of your existing code will continue to work
as expected.

For breaking changes, controllers are no longer registered as
singletons inside the beanFactory, but instead are stored internally
inside the controllerManager. This will only affect you if you were
injecting controllers into other controllers, which I would argue
isn't the best practice.

Also, controllers no longer support the @directory annotation and
instead will rely on conventions to determine where their related
views are located.

Right now modules only contain controllers and views, not layouts yet.
I'll try to write some documentation for modules in the near future,
but for now just pretend they don't exist. Unless of course you're
feeling adventurous and want to dig through the code and play around
with them. :)

It's a pretty big update, so if you upgrade and see any issues, let me
know immediately.

-Tony