AWG Blogs

Sunday, May 23, 2010

The Original MVC

The MVC is the object of somewhat of a religious ferver in the web development community. Many frameworks -- e.g. Zend Framework, CodeIgniter, etc. -- appear to me to be attempts at literal instantiations of the paradigm. Those frameworks have little appeal to me because they lock the developer into this single way of doing things. When the inevitable time comes that that way is not appropriate, the developer must resort to the framework's many workarounds, e.g. helpers or plugins (to plug the leaks? :)), extended classes, or hacks.

I wondered if the MVC is being used as it was originally intended so I researched it and read some of the creator's comments.

The MVC wasn't even called the model-view-controller; originally it was the model-view-editor. Additionally it was conceived by Trygve M. H. Reenskaug to solve the problem of network problems of the yards of the Aker Group in Norway. I think the idea got over-subscribed to by wannabe developer purists and their disciples, and as a consequence was bastardized into the impractacal forms we see depicted today around the internet.

Now, I admit, I haven't done complete dilligence on this research and so my conclusions may be premature or inaccurate. But when I see what I perceive to be serious inconsistencies between a implementations/interpretations of a model, I have to question whether the model as we know it is itself in its purest form.

For example, the Zend Framework, in which I'm no expert, apparently presupposes a single view delivered to a user at one time. If the model data must be aspected on the page, the developer has to use helpers or the ActionStack or some other hack to get the data on the page. I think this is a too-strict, too-literal, and consequently untenable, implementation of the MVC.

By contrast, the author of MVC appears to indicate multiple views presented can be the norm:
A user task may commonly be better performed with several Views present on the screen at the same time. The user will want to manipulate these Views through pointing at them, through selection in menus, or through some other means. Commands like selection typically apply to several Views at the same time. The purpose of an Editor is to establish and position a given set of Views on the screen, to coordinate them and to provide the user with a suitable command interface.

Some comments by Reenskaug lead me to wonder whether the MVC or MVE is applicable to web development at all:
Conversely, a view should never know about user input, such as mouse operations and keystrokes. It should always be possible to write a method in a controller that sends messages to views which exactly reproduce any sequence of user commands. http://heim.ifi.uio.no/~trygver/2007/MVC_Originals.pdf
How can we conclude that a PHP script can be an implementation of a "view" then? Is this what Reenskaug meant when he referred to the "perverted variants" of his model found in texts? http://heim.ifi.uio.no/~trygver/

Sunday, May 16, 2010

CodeIgniter versus MyEDB

CodeIgniter like most CMS's and their underlying frameworks assumes entities are mapped to tables in relational databases. MyEDB presumes the MyEDB model of data (http://www.myedb.com).

CodeIgniter like most (PHP based) CMS's assumes the view (in the MVC pattern) is composed of templates in the form of PHP files (some CMS's use non-PHP files but are nonetheless PHP interpretable in some form) which are passed parameters ala Smarty. MyEDB uses XSLT.

CodeIgniter allows the user/developer to invoke a single entry point to the system through a single controller class action pair. MyEDB allows the client to invoke a series of class action pairs, in essence multi-action controllers (maybe like Spring multiactioncontrollers? but more specifically multiple controllers) to be executed iteratively in sequence through the HTTP posting of appropriately named array variables, specifically class method pairs.

In CodeIgniter (and Zend Framework, and CakePHP, and... you get the picture) the view is an intrinsic component of the controller (defeating the notion of controller view independence). In MyEDB, the "view" is abstracted from the "controller" by a series of processing steps (see image below), ensuring total flexibility. In short, in MyEDB you are not chained down to a single way of doing things from an MVC perspective!

MyEDB Source
myedb.com

Thursday, May 6, 2010

Uploading InfoPath Form Templates

So, I'm working through Sharepoint 2007 for Dummies, and I'm on page 200, and I go to upload my test form, and get The restricted trust level is not supported. Quickly googled, and found http://sharepointknowledgebase.blogspot.com/2009/03/restricted-trust-level-is-not-supported.html. So I follow the fellow's excellent advice (Tools - Form Options - Security and Trust - Domain) and the error goes away.


But it can be that easy. I just get a new error (what do I expect right?): The form template is not browser-compatible. So google around again, and finally decide to do the following: Tools - Form Options - Compatibility - (check) Design a form template that can be opened in a browser or InfoPath. Click Ok. Then an error shows up in my form. It's the combo box, apparently not supported on the web. So I delete it; error goes away.

Save the form and try uploading again, first clicking Verify. Now it says This form template has not been correctly published to be browser-enabled. Open the form template in InfoPath Design mode, and click Publish Form Template in the Design Tasks task pane. Follow the steps in the Publishing Wizard to republish the form template, and then try again. So I do as instructed, choosing to "Publish this form template as a template in a document library." Published it. Still get the same error. Then, I tried selecting "To a network location" and leaving the third screen in the Publishing Wizard blank per http://www.novolocus.com/category/sharepoint/infopath/, Next, Ok, Next, publish. This saved the form again. I then tried verifying the form once more in the Upload Form Template page and it verified...I then uploaded it, got another error: The timer job for the operation has been created. However, it cannot be run because the administrative service for this server is not enabled. To run the timer job, use the stsadm.exe command line utility (stsadm.exe -o execadmsvcjobs). Googled again and got http://vspug.com/ssa/2007/10/22/a-deployment-or-retraction-is-already-under-way-for-the-solution-publishing-infopath-form/. So I start the Windows SharePoint Services Administration service, run the stsadm.exe -o execadmsvcjobs command, check the Manage Form Templates page, but see that my form is "Installing". Found this: http://www.infopathdev.com/forums/p/8034/29193.aspx, tried the suggestions, including turning on my other sharepoint server in the farm that happened to be off, but that didn't fix it. I was able to delete the "Installing" form templates through the timer definitions page and subsequently through the Manage Form Templates. Still need to figure out why it won't finish "Installing". Later, I noticed that the second Sharepoint web frontend server is low on disk space. Checking how a 25GB drive can fill up so quickly, I used windirstat and found that C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\LOGS is taking up 21 GB of space. Huh? So I delete all those log files and try uploading again. Still getting "Installing" forever....
Finally I decided that the second Sharepoint server, which is sitting on a VMware Workstation guest, needs to be removed from the farm as it appears to be experiencing issues, e.g. the ever-increasing logs mentioned earlier (containing entries like "Tracing Service lost trace events," as well as a failing system clock. As soon as I removed the second server, and attempted the template upload, the results were successful.

Saturday, May 1, 2010

Replacing Form Action Scripts with sed

I needed to replace all form action scripts in all my XSLT templates, specifically to make the script relative to the current path. So I did:
find . -name "*.xsl" -type f -exec sed -i "s#\([\"|'|>]\)/index.php#\1index.php#g" {} \;
There are a few of things to notice about this command:

I used a double quote and not a single quote for the sed script namely because A single quote may not occur between single quotes, even when preceded by a backslash. *

The parenthesis required backslashes because sed apparently is not running in extended mode on my machine.

The argument to sed needs to be quoted to avoid being parsed by the bash shell interpreter. Aside the from the parenthesis the only other character needing escaping is the double quote in the regex. Even the \ don't need further escaping because a double quote string preserves the literal value of all characters except \, $, and `. The backslash has its special meaning only if followed by ", $, `, \, and newline. *http://answers.google.com/answers/threadview/id/496910.html