ColdMVC 2.0

[Tony Nelson]

All,

Lately I've been working on some pretty large changes to routing in
ColdMVC. I'm guessing most of you haven't spent much time on how
routing works, so you probably won't even notice a difference.
However, since the updates will include some breaking changes, I'm
going to release them as a part of ColdMVC 2.0.

While I'm at it, I'm going to be re-organizing ColdMVC's internal
directory structure, since it wasn't very well thought out in the
first place. Seriously, why did I put almost every component inside a
single directory? I really don't know.

Also, are there any plugins that you think would make a decent
candidate for being included in the core framework? Ideally I'd like
to keep the framework itself really small, but if there are plugins
that everybody should be using, maybe they should be part of the
framework.

Let me know your thoughts,
Tony

[Tony Nelson]

I was thinking about adding support for Railo in version 2.0.
Originally my main reason for not supporting Railo was its lack of
Hibernate ORM. Since that's no longer the case, the main barrier to
Railo support is ColdMVC's use of an undocumented feature in Adobe
ColdFusion that allows you to create global variables using the
underlying page context. This is done to add new "scopes" to your
application, namely "params", "flash", "coldmvc" and "$".

Since 2.0 already includes a handful of breaking changes, albeit
nothing too terrible, I was thinking about refactoring how these
global scopes are created and used in ColdMVC. Long story short, I
want them to still be available, but not globally. Global variables
are typically considered bad and can make testing somewhat difficult.

* Note: since the coldmvc scope and $ scope are essentially the same
thing, I'll only refer to it as the coldmvc scope for the rest of this
message.

Here are some thoughts on how the scopes could work:

The scopes would only be available to controllers. The params scope
and flash scope would be passed to each action as named arguments.
Since they're named arguments and will always be passed to the
actions, you shouldn't need to defined them in your method definition
or prefix them with "arguments." when using them inside your actions.
For the most part, your controller code would remain unchanged. The
coldmvc scope would be injected into each controller automatically and
set into the variables scope after the controller is created, as well
as passed to an init() method if it existed on the controller and you
wanted to use helpers during object instantiation.

Aside from controllers, other components in your application would not
have access to any of these scopes by default. Typically the params
scope and flash scope should only be accessed in the controller
anyways. If you need to access a param inside a method in a service,
the values should be passed in as arguments. As for the coldmvc scope,
I would add logic to have the beanFactory to look for a coldmvc
property on singleton components to autowire the helpers into the
component.

As for views, I don't think they should have access to any of the
scopes. The params scope is automatically copied into the view's
variables scope and the flash scope shouldn't be accessed outside of a
controller. As for helpers, most of the time your view should be using
viewHelpers for common helper functionality so I don't see a huge need
to have the coldmvc scope automatically added to views, although I
could easily add it if we feel it's necessary.

I haven't made any of these changes yet, so if anyone has any ideas,
suggestions, objections or concerns, please speak up.

I'd like to get version 2.0 released sometime this weekend, so now's
your chance to help mold the framework.

Thanks,
Tony

[Joe]

Great to hear about the Railo support. I attempted to battle threw it
with Railo but hit the pageContext obj with the adobe hidden scope and
got owned.

My only concern would be to make helpers not in the framework still
available in the views.

I can't think of anything else right now.

[Ryan Ricard]

I'm on board. Following up on Joe's concern, will the helpers be
available to the views and custom tags?

[Tony Nelson]

Yes. Views and tags go through the same code generation process, so
the helpers and viewHelpers would be available to both.

Now that I think about it, it might be best to expose the coldmvc
helpers to the views and tags, since a lot of the time the tags end up
delegating their logic to underlying components using the factory or
form helpers.

In that case, it will be up to the developer not to abuse access to
the helpers and give their views too much responsibility and power.
Meaning, while technically possible, don't do this on a view: <cfset
users = coldmvc.factory.getBean("dao").list("user", { sort="lastName",
order="asc"}) />

[Tony Nelson]

I'm thinking about removing the "controller" key from the config.ini
and the @action annotation on controllers and instead have the default
controller and action always be "index". It will make the default
routes a lot easier to use, since you don't have to worry about
specifying a default action for each controller.

Thoughts?

[Tony Nelson]

I've almost completed the 2.0 updates. Before I commit the code, I
figured I should let everyone know about the breaking changes. For the
most part, they shouldn't effect you that much, but I wanted everyone
to be aware just in case. Without further ado...

ColdMVC will now have its own bean factory. This will remove ColdMVC
beans from your app's bean factory. ColdMVC beans will no longer be
automatically wired into your applications. To inject a ColdMVC bean,
you'll need to add an "@inject coldmvc" annotation to the property.

The internal ColdMVC directory structure will be completely
overhauled. If you were previously creating or extending ColdMVC
components, you'll want to update your code.

The following scopes will be updated:
- "coldmvc" and "$" will no longer be global. They will be
automatically injected into views, but they will not be automatically
injected into controllers. To access them inside your components,
you'll need to add a "coldmvc" property with an "@inject coldmvc"
annotation.
- "params" and "flash" will no longer be global, but instead they will

be passed to each action as named arguments.

You will no longer be able to set the default controller for your
application. Instead, the framework will expect the default controller
to be "index".
You will no longer be able to set the default action for a controller.
Instead, the framework will expect the default action to be "index".

To define your application's beans using an XML file, the framework
will now look for a "/config/beans.xml" file rather than a "/config/
coldspring.xml" file.

The folling helpers will be updated:
- link.to() will no longer support a querystring argument. I'll
discuss this more with the routing updates.
- factory.get() will be changed to factory.getBean()
- factory.has() will be changed to factory.containsBean()
- user.id() will be removed in favor of user.getID() and user.setID()

The following helpers will be removed:
- application
- cookie
- database
- event
- flash
- params
- request
- session

The following components will be removed:
- coldmvc.Component
- coldmvc.Helper
- coldmvc.LayoutController
- coldmvc.Prototype
- coldmvc.Scope
- coldmvc.Service
- coldmvc.Singleton

The following events will be removed:
- preAction:{controller}
- postAction:{controller}
- preAction:{controller}.{action}
- postAction:{controller}.{action}
- preLayout:{layout}
- postLayout:{layout}
- preView
- postView
- preView:{view}
- postView:{view}
- preLoad:{model}
- postLoad:{model}

The following plugins will be deprecated:
- Breadcrumbs
- Cells
- Mapper
- Security
- Serializer (will be added to core)
- Tabs

If anyone has any questions or concerns about the updates, or anyone
wants to know why things changed, please don't hesitate to ask. I
thoroughly enjoy talking about the inner workings of the framework. :)

-Tony

[Tony Nelson]

I just pushed version 2.0 from development to master, meaning ColdMVC
is officially on version 2.0.

In the upcoming weeks I'll be updating the documentation to reflect
the changes. In the meantime, if you're curious on how something
works, don't be afraid to ask as it will probably force me to write
some documentation for it.

If you need the previous version of ColdMVC, I created a version 1.0
branch at https://github.com/tonynelson19/ColdMVC/tree/1.0

[Tony Nelson]

I should note that version 2.0 doesn't fully support Railo yet, as
Railo doesn't support Javadoc annotations for whatever reason.

On Nov 6, 9:52 am, Tony Nelson <tonynelso...@gmail.com> wrote:
> I just pushed version 2.0 from development to master, meaning ColdMVC
> is officially on version 2.0.
>
> In the upcoming weeks I'll be updating the documentation to reflect
> the changes. In the meantime, if you're curious on how something
> works, don't be afraid to ask as it will probably force me to write
> some documentation for it.
>
> If you need the previous version of ColdMVC, I created a version 1.0

> branch athttps://github.com/tonynelson19/ColdMVC/tree/1.0

> ...
>
> read more »