| Lack of time or perhaps desire? + Meiliox described in detail, part 1. | |
| by Sir Meili | |
Friday, March 18, 2005 - Hello all out there who read this (read: me ;) ). As you can see there are no noticable changes to the site recently. Well in reality that is mistaken, a lot is going on in the background as I move things around. I have just found myself lazy when it comes to actually writing about anything, but I will do so now and give you a full recap of what's going on. | |
I am still trying to work out in my head how most of this will be going down. I have given up wholy on the 'events' config as the sole way of handling page processing. In an earlier version of Meilibox non-OOP my and my friend switchprog (ok mostly switchprog) used a task oriented flow for the page. I found the flow a wonderful idea. It allows a great flexibility for data verification and task looping. Since I have become accoustomed to programming pages this way I have put heavy consideration in using this same methodology in MeiliBox OOP. Basically it would be a merger of the two. Here is the code for the current Meilibox non-OOPindex.cfm <cfinclude template = "mb_settings.cfm" />
<cfscript>
if (trim(MBF.MB_action(MB_flow)) eq 'custom') {
MBF.MB_populate_template_params(MB_flow);
}
else {
MB_flow = MBF.MB_populate_flow(MB_flow);
MBF.MB_populate_template_params(MB_flow);
}
</cfscript>
<cfif not structisempty(form) or MB_method eq "post">
<cfif MB_autoVerify eq "on">
<cfoutput>#MBF.autoVerify(MBF.MB_strip_form_struct(form))#</cfoutput>
<cfelse>
<cfif fileExists("#request.meilibox.settings.base_path & request.meilibox.MB_inc_file_path#verify/verify_#request.meilibox.MB_inc_file#")>
<cfinclude template="#request.meilibox.MB_inc_file_path#verify/verify_#request.meilibox.MB_inc_file#">
</cfif>
</cfif>
<cfif structisempty(request.meilibox.err)>
<cfif MB_autoquery eq "on">
<cfoutput>#MBF.autoQuery(MBF.MB_strip_form_struct(form))#</cfoutput>
<cfelse>
<cfif fileExists("#request.meilibox.settings.base_path & request.meilibox.MB_inc_file_path#act/act_#request.meilibox.MB_inc_file#")>
<cfinclude template="#request.meilibox.MB_inc_file_path#act/act_#request.meilibox.MB_inc_file#">
</cfif>
</cfif>
<!--- make new task/stage/action params from MP_passto param --->
<cfif structisempty(request.meilibox.err)>
<cfscript>
if (isdefined('MB_passto')) {
MB_flow = MBF.MB_new_flow(MBF.MB_action(MB_passto),MBF.MB_stage(MB_passto));
}
else {
if (mb_passto_proc eq 'next') MB_flow = MBF.MB_new_flow(MBF.MB_action(MB_flow),MBF.MB_next_stage(MB_flow));
else if (mb_passto_proc eq 'self') MB_flow = MB_flow;
else if (mb_passto_proc eq 'close_win') MB_flow = MBF.MB_new_flow('custom','close');
}
if (trim(MBF.MB_action(MB_flow)) eq 'custom') {
MBF.MB_populate_template_params(MB_flow);
}
else {
MB_flow = MBF.MB_populate_flow(MB_flow);
MBF.MB_populate_template_params(MB_flow);
}
</cfscript>
</cfif>
</cfif>
</cfif>
<cfif fileExists("#request.meilibox.settings.base_path & request.meilibox.MB_inc_file_path#var/var_#request.meilibox.MB_inc_file#")>
<cfinclude template = "#request.meilibox.MB_inc_file_path#var/var_#request.meilibox.MB_inc_file#">
</cfif>
<cfif show_layout eq 'true'>
<cfmodule template="#mb_layout_template#.cfm" mode="start" />
</cfif>
<cfinclude template = "#request.meilibox.MB_inc_file_path#dsp/dsp_#request.meilibox.MB_inc_file#">
<cfif show_layout eq 'true'>
<cfmodule template="#mb_layout_template#.cfm" mode="end" />
</cfif>
As you can see it consists of four distinct files (this really sucks for code reuse, but when you get used to using this style flow it rocks): dsp (display), var (variables), verify, and act (action). Here is a short description of each: dsp: These display files contain mostly HTML and very little coldfusion logic. basically there is only enough CF logic to insert the dynamic data.var: The 'var' files are where the queries and variable setting happens. there is very little complex CF in this page. verify: The 'verify' files are basically just that. They are where you verify data before it is sent to the 'act' files. If there is an error (denoted by setting a ket to the 'request.meilibox.err' structure) then meilibox automatically skips the 'act' file and returns you back to the previous stage (not really the previous stage as the 'verify' and 'act' files for a specific stage are tied to the page that calls them.) act: This is where most the action happens (sorry for the pun). These pages mostly contain the Inserts, Updates or any other action that can be caused by clicking a link or submitting a form (actions can only be called if a form is submitted or the mb_method variable is set to post). Now, "how", do you ask does this pertain to my oop version? Simple, I want to replace the page calls with event calls. There is already a definition for the Flow in the non-OOP version that is basically as follows: A snippet from the mb_settings file:<cfscript>
if (not isdefined('request.meilibox')) {
request.meilibox = structnew();
}
if (not isdefined('request.meilibox.err')) {
request.meilibox.err = structnew();
}
request.meilibox.MB_inc_file_path = ';
request.meilibox.MB_inc_file = ';
request.meilibox.settings = structnew();
/*
This structure contains a representation of the flow control of this module.
The keys of the flow structure correspond to the child elements of the navigation menu on the left.
Each key (meilibox.flow.controlcenter) is a string that holds task/stage/action parameters.
Currently controlcenter contains a "manage" task which mainly corresponds to managing Contrl Center services, and an "add" task.
The "manage" task is made up of 2 stages (view and manage). The view stage is made up of the "view" action.
The task name and the action name are used together to include the appropriate file: controlcenter.view.cfm. This file will list the Control Center services.
*/
request.meilibox.flow_delimiter=".";
request.meilibox.flow=structnew();
request.meilibox.flow.action_index=0;
request.meilibox.flow.stage_index=0;
request.meilibox.flow.actions=arraynew(1);
request.meilibox.flow.stages=arraynew(2);
request.meilibox.flow.shorthand = structNew();
/* user definable settings. Possible needs to be moved to a separate file.*/
request.MeiliBox.settings.path_delim = iif(cgi.server_software contains 'Microsoft',dE('\'),dE('/'));
request.meilibox.settings.base_path = getDirectoryFromPath(getCurrentTemplatePath());
request.MeiliBox.settings.base_url = "http://#cgi.server_name#/";
/*
Turn on shorthand.
This allows you to use short hand in the url or form when calling pages.
For example instead of using form_page you can send fP and this will
convert it using the structure contained in mb_shorthand.cfm.
*/
request.meilibox.settings.shorthand = "on";
/* shorthand identifiers */
request.meilibox.shorthand=structnew();
/* actual flow setup. This can be bypassed by using the 'custom' action (ie: custom.news/index) */
request.meilibox.flow.actions[1] = "view_main";
request.meilibox.flow.stages[1][1] = "main";
request.meilibox.shorthand.view_cc.view="ControlCenter/view";
request.meilibox.flow.actions[2] = "view_cc";
request.meilibox.flow.stages[2][1] = "view";
request.meilibox.flow.actions[3] = "view_mystrato";
request.meilibox.flow.stages[3][1] = "main";
request.meilibox.shorthand.view_mystrato.main="MyStrato/main";
request.meilibox.flow.actions[4] = "manage_cc";
request.meilibox.flow.stages[4][1] = "edit";
request.meilibox.shorthand.manage_cc.edit="ControlCenter/edit";
request.meilibox.flow.stages[4][2] = "close";
request.meilibox.flow.actions[5] = "manage_cc_priority";
request.meilibox.flow.stages[5][1] = "changepriority";
request.meilibox.shorthand.manage_cc_priority.changepriority="ControlCenter/changepriority";
request.meilibox.flow.stages[5][2] = "view";
request.meilibox.shorthand.manage_cc_priority.view="ControlCenter/view";
/* Flow control functions */
/* Functions are in a CFC called MB_functions.cfc. When you need to call to a function from the page, call it by MBF.function_name(arg1, [arg2...]) */
MBF = createObject('component','mb_functions');
</cfscript>
In this code you'll also see the 'shorthand' definitions mixed with the flow, please excuse those for now, that's another writing. What normally happens here is when you send the page request you send param called mb_flow in the format of action.stage. Where in most cases (shorthand turned off or no shorthand definition for that stage) the stage is sort of relative path from the root of the mb application. now that's not 100% correct cause the last element in the list (usually '/' delmited) is stripped out, so as listed above the 'close' stage's 'dsp' file can be found in '/mb_app_root/dsp/dsp_close.cfm'. Now all shorthand does is allow you to send a shorter stage name (especially helpfull if you use subfolders to organize your files). For instance the stage changepriority (in the manage_cc_priority action) is linked to the shorthand key 'manage_dd_prority.changepriority' key (you'll notice that the key is the flow). this one sets the action to ControlCenter/changepriority and when the stage is converted to a file location it is parsed to '/mb_app/root/ControlCenter/dsp/dsp_changepriority.cfm'. I hope that's not too confusing. When I convert the OOP version to use this, I will simply replace the pages with events. This will drastically change my event flow system and queueing system, but I think for the better, and it will allow for great data verification. not only that but give you the ability to return to the last 'stage' in the action. I'm not sure how this will work. I am currently working on getting a developement plan with Crystal Tech to do my testing and developement on. Maybe you don't understand my love for this flow. Hopefully, though, you see the benefits of it. There are more files needed for this to finish, and soon I will post writings on those as well as I continue my work on MB, but for now I better get back to work. Please leave comments and understand that sometimes my writing skills aren't that great. I am by far a better programmer than a writer. Bye for now and have fun ;) | |
| (1)Comments | < Back |