Mach II Team Meeting December 20, 2009

Attendees: Peter Farrell, Matt Woodward, Kurt Wiersma, Mike Rogers

Table of Contents

1. Mach-II 1.8 Final - Remaining Tickets
2. Mach-II 1.9 "Integrity"
   • Endpoints
   • Validation
   • Packages
   • Other general features possibly for 1.9
3. General Project Discussions
4. Features for 1.9 and Applicable Milestones
   • Milestones for 1.9
5. Features for 2.0
6. Other Projects

Mach-II 1.8 Final - Remaining Tickets

Ticket (trac-wiki) #474 "enhancement: 'Overwrite' boolean attribute for call-method command (closed: fixed)") - add overwrite boolean for event-beans when call-method is used

• Submitted by Mike Rogers
• Peter, Matt, and Kurt concur this would be useful
• Will be added for 1.8 final
• Ticket assigned to Mike

Ticket (trac-wiki) #471 "enhancement: Add support for IE conditional in the javascript tag in the ... (closed: fixed)") - add conditional support for IE for script tag in HTML helper property

• Peter taking this on

Ticket (trac-wiki) #412 "defect: Error in formTagBuilder.cfm (closed: fixed)") - error in form tag builder due to screwy way CF 9 handles nulls (specifically in ORM in this case)

• We'll add in a check to see if the variable still exists and if it doesn't, we'll return a zero-length string
• This won't break anything in Railo or OpenBD

Ticket (trac-wiki) #472 "enhancement: Event-bean should support 'prefix' like inner-bean does (closed: wontfix)") - support prefix in event-bean since it's in inner-bean?

• Consensus was no--couldn't think of a use case where it would be necessary, and there are definitely simple workaround
• Peter resolving as "won't fix"

Ticket (trac-wiki) #473 "enhancement: All form tags that generate names as well as 'form' and 'bind' should ... (closed: fixed)") - support prefix in form tag library form and bind

• Will fix for 1.8 final
• Peter accepted ticket

Mach-II 1.9 "Integrity"

Three main features: endpoints, validation, and packages

Endpoints

• Will release spec soon for public feedback
• At CFML engine level we don't have a nice servlet-type construct to respond directly to requests

  • e.g. cfchart works this way--has its own servlet

  • would be nice to handle routing like servlets at the Mach-II level

  • lets registered endpoints respond to requests

  • don't need a full Mach-II request lifecycle for some things going on in Mach-II, e.g. HTML Helper property to return concatenated javascript files

  • better support for AJAX requests

  • support for REST at the top level of the framework

    • can't really support this properly at the event handler level

      • works, but not in all situations
      • typically REST services will have different authentication than the general Mach-II requests

    • REST endpoint could interact directly with service layer

  • basically endpoints are simple, lightweight servlet handlers

    • can still tie into the full M2 request lifecycle as needed

  • endpoint will be a new framework class (like listeners, filters, etc.)

  • possible bundled endpoints

    • cfcontent to serve documents

    • scheduled task endpoint--make these easier to configure, set up, etc.

      • again, since full m2 request isn't needed, views aren't rendered, etc. this makes more sense

    • ajax endpoint

    • REST endpoint

    • all the bundled endpoints will be pretty generic and would have to be extended by the developer since the functionality would be very specific

  • will likely support CFC endpoints as well as simple cfm files

    • could specify whether CFC endpoints are singletons or not

  • implementation

    • generic endpoint--runs through index.cfm
      • additional parameter of "endpoint" (as opposed to "event")
      • could be used to serve up images, javascript, etc.
      • e.g. m2 dashboard loads up images, etc. through full m2 events--much slower than if using an endpoint-style approach
      • could also implement a Compass-like CSS framework
      • would also be used by the HTML helper property
      • custom endpoint path
      • due to way cf works a file would have to exist to handle the request even if it's blank, or hit a CFC directly
      • in usage might wind up having to use rewriting at the web server level to get true REST-style URLs

  • eliminates the need for view handlers that have been discussed in the past

  • could call an endpoint from within the context of a mach-ii request to get back endpoint results as part of a mach-ii request

Validation

• in some ways this ties into endpoints since validation can be too complex to easily handle 100% on the client side

• spec is well underway--should be released for public feedback before long

• validation would be able to be applied to both client and server

• want to bind to event-bean and form tags with respect to validation

• validation rules need to be configurable and allow for passing in of a context

  • e.g. logging into the web site and registering both involve the user object, but the validation is completely different

• validation will be accessible via the mach-ii utility connector so the validation is accessible in objects that are outside of mach-ii's control, e.g. service objects

• support for numerous different validation types

  • goes much deeper than simple required fields, date ranges, numbers, etc.
  • validation across fields (e.g. must provide state if country is US)
  • leverage expression syntax so people can build custom validators (e.g. extend abstract validator CFC)

• validation messages

  • support i18n
  • messages must support placeholders

• discussed various ideas for xml syntax

  • current spec is out of date--needs to be updated based on investigation of other validation frameworks

  • have looked at Spring, Struts 2, iScreen, ValidateThis, and Hyrule

  • iScreen built around concept of validation sets--can extend existing validation sets and override, so very little repetition

    • iScreen also supports "fast failing"--meaning if one validation fails, don't continue with other validation

  • Spring handles client-side validation via ajax requests so all validation is done on the server side essentially

    • advantage is all the server validation rules can be more complex than what you can do with javascript in some cases
    • downside of Spring is the validation was all done in classes, so couldn't be configured in a configuration file, so less re-use possibilities

  • Hyrule is annotation based

    • non-starter in our opinion--might be CF 9 specific (?)
    • also annotations in a class don't support multiple validation contexts--this is where annotations fall down and there's even a push against this in the Java world

• would use ColdSpring or another DI engine to integrate with validation

• dashboard integration would generate a lot of the xml so it wouldn't have to be written by hand

• ton of implementation details still need to be worked out, but we do have the general concepts and direction we want to go

• since in the CF world we're a bit late to the game as far as validation goes, we have the benefit of studying what's been out there for a while and hopefully create something that takes the best of each approach

• why reinvent the wheel?

  • based on the other frameworks we've looked at it would be more work to contribute to another project than it would be to create our own
  • in a lot of cases the base concepts were so different it would be changing the existing frameworks rather radically to go the direction we want to go

• client-side validation--need to support different javascript frameworks?

  • gets into using endpoints probably--different endpoints for different javascript frameworks

• use domain class metadata or a validation service?

• leaning more towards a validation service

  • can include metadata in a domain class to indicate what validators apply
  • probably won't go with constraints declared directly in the domain classes

• iScreen will serve as our model

• very important particularly with this sort of feature to get people using it early for feedback

  • we can't possibly think of all the different ways everyone is going to want to use validation, so the more feedback the better

    <validation>

        <includes>
            <include file="" />
        </includes>

        <validators>
            <validator id="string" path="StringValidator" />
        </validators>

        <sets>

            <set name="registration">
                <bean path="address" ref-set="address" />
            </set>

            <set name="addresss">

                <use validator="string">
                    <map from="firstName" />
                </use>
                <property name="firstName">
                    <use validator="string"/>
                </property>

                <use ref="address">
                    <map from="address"/>
                </use>
                <property name="address">
                    <use ref="address"/>
                </property>

            </set>

        </sets>

        <resources>
            <resource file=""/>
        </resources>

    </validation>

Packages

• debating whether or not to include this in 1.9; might make more sense for 2.0

• spec is ready for feedback with a few updates--will release this soon

• started life as "include enhancements"

  • wild-card matches for XML includes (ant-path matching)

• idea of packages is similar to "plugins" in other frameworks--more or less application fragments that can be dropped in

  • expands concept of includes
  • allow parameter nodes inside include definition
  • gets its own prefix for events, listeners, etc. (e.g. if you included a twitter package, everything might be prefixed with 'twitter.')
  • this is bound at application startup time
  • more integrated than modules--no parent/child relationship, but is layering one Mach-II application or subset of functionality on top of another
  • idea is packages are more discrete sets of functionality--e.g. a captcha plugin, security plugin
  • modules are more appropriate for full sub-applications
  • need to build exchange/download server functionality that would live on mach-ii.com

Other general features possibly for 1.9

• i18n better supported at the framework level in general
• better support for negotiation of SSL/non-SSL urls
  • mark certain event handlers to be required to be executed over ssl
  • would be tied into environment property
  • one proposed solution is addition of secure="true" to the event-handler tag
  • if an event is flagged as secure and that isn't in the url, it would automatically redirect to the secure URL

General Project Discussions

• move to a milestone-type release for 1.9 and 2.0 instead of typical alpha, beta, etc.
  • focus on completing specific features and releasing them in milestones
• need to come up with a complete high-level feature list for 1.9 and 2.0 and decide on what goes in which release and what the milestones would be

Features for 1.9 and Applicable Milestones

• validation - m4
• ant-path matching for includes, but probably not packages - m1
• endpoints - m3
• i18n improvements (ties in with validation) - m2
• ssl auto-negotiation - m2
• other fixes and improvements to existing features - m1
  • htmlhelper improvements (js compression & concatination)
  • bootstraper loading page
• if any bugs come up in 1.8 we'll do a 1.8.1 if necessary, but won't plan on this release
• with 1.9 the dashboard will be part of mainline framework development and won't be a separate project and download

Milestones for 1.9

• M1: ant path matching for includes, improvements to html helper property, "loading page" for bootstrapper
• M2: i18n support, ssl auto-negociation support
• M3: endpoints
• M4: validation

Features for 2.0

Discussion ensued. Kurt will be leading research effort.

Other Projects

• Single bundled up download to get people going faster (lets people choose Railo or OpenBD to be included, or could use CF they installed).
• Package exchange on mach-ii.com
• Dashboard improvements
• Dashboard will be native in Mach-II Integriy, and will also include the Mach-II skeleton