Packaging View Oriented Code

OK, a clear strength of CFML is custom tags. NOBODY DOES IT BETTER! :slight_smile: When it comes to controllers or model CFCs are the way to go. When it comes to VIEW then tags are preferred by many. Especially preferred by designers. Since we hopefully work with designers in view and layout pages this would be good tech. Note: it would be optional of course, not saying force anyone to use this.

With that said, in ColdBox the question is how can we do it best. Over and over again one key thing the community that does this thrives on is using cfimport for tag prefixes.

<jui:tabs id=“myTabs”>
<jui:tab title=“tab 1”>Tab one contentjui:tab
<jui:tab title=“tab 2”>Tab two contentjui:tab
<jui:tab title=“tab 3”>Tab three contentjui:tab
</jui:tabs>

Typically this is done by placing the library in a shared common folder. My goal BTW is to take our Collaboration technology and port it to use for ColdBox. Our library solves some other issues also. It manages data passed to these tags as well as managing JS and CSS. So we will want to deal with integrating those features also of course. :slight_smile:

Thanks for any and all input that follows.

One word…

CBHelper

Andrew, how does that help us create custom tags and libraries? Can you grace us with an overstated answer for the less clued in types that didn’t get it in “one word”?

Appreciate your thoughts and answers.

John,

Are you asking how do you use tags with ColdBox?

If that’s the case, remember that views and layouts are just ccm templates, so you use them as normal.

signature0.jpg

Luis F. Majano
CEO
Ortus Solutions, Corp
www.ortussolutions.com

ColdBox Platform: http://www.coldbox.org
Linked In: http://www.linkedin.com/pub/3/731/483
Blog: http://www.luismajano.com
IECFUG Manager: http://www.iecfug.com

Social: twitter.com/lmajano facebook.com/lmajano

I get the idea none of you ever looked at COOP as you don’t appreciate it’s not just custom tags.

  • Tag Libraries via CFImport
  • Management of included CSS and JavaScript, only once and in order
  • Integrated management of data collections passed to tags
    I would be glad to do a hangout to explain it better or get questions answered.

Goals:

  • Make sure it is portable to regular and module style apps.
  • Make sure it taps into how ColdBox (ContentBox) and such handle CSS and JS if at all.
  • Make sure it works with LogBox, CacheBox and such as possible.
    :slight_smile:

John, do you have any online documentation or examples of your framework people can look at?

Thanks!

~Brad

ColdBox Platform Evangelist
Ortus Solutions, Corp

E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com

My docs for Collaborate have not be generated yet but they are VERY similar to the COOP docs. We found the name COOP did not market well. :slight_smile:

https://code.google.com/p/cfcoop/wiki/COOP

Another thing we were doing is generating AJAX client classes in JS to work with the remote server proxy style via AJAX. I want to adapt that to work with ColdBox also if it makes sense. Have not looked at that yet.

P.S. Note on difference is we would use the ColdBox controller vs the CO-Processor in the original use case.

Here is one question in specific. We use “PRE-DOM” coding to set attributes from the controller for the tags used on the view page. In Collaborate (COOP update) we were using the prefix _preDOM along with the ID of the element.

_preDOM.myList = {
data = “red,green,blue”,
selected = “green”
}

My thought would be to pass this through the rc as follows and have the custom tag inspect the caller scope for the rc._preDOM variable structure.

We also in COOP like the idea of some standard events for managing page requests. (The links to these functional docs are included here.)

  • onPageStart()
  • onFirstCall()
  • onPostback()
  • beforeViewCall()
  • onPageEnd()
    The onPageStart and End are handled well enough with standard events. The other three can be handled by code logic also but again we want to package it to make on the fly coding as simple as possible. Notable among these would be the form handling power in Collaborate (rework of COOP). The standard modes for COOP forms are ‘add,edit,view’. If the data attribute is passed in and it shows one or more records this tag will smartly set to either edit or view mode. This allows the designer (view) to set which form elements will show or not based on the “mode” with which the form was presented.

( Some of this will need to be reviewed for things like Angular JS and KnockoutJS or other client side templating solutions. )

Oh, I am wondering if we might want to do a MIXIN approach to something like this. The naming convention would have to be more detailed and use something to parse it as with ColdBox the target is the method vs a page controller. Thus we could name things like cart_pageFirstCall(), cart_postBack(), cart_beforeView(). The before view call is to place code that is common to firstCall and postBack in a common location. It also lets normal controller code used to interact with the view be place in a universal and logically named location.

Thoughts and questions of course welcome.

For this John,

You can replicate using Interceptors. Apart from the core interceptors you can add your own custom interceptors anywhere you like as well. But you have the majority already included.

signature0.jpg

Luis F. Majano
CEO
Ortus Solutions, Corp
www.ortussolutions.com

ColdBox Platform: http://www.coldbox.org
Linked In: http://www.linkedin.com/pub/3/731/483
Blog: http://www.luismajano.com
IECFUG Manager: http://www.iecfug.com

Social: twitter.com/lmajano facebook.com/lmajano