Sunday, November 30, 2008

Re: MVC falling to pieces for modern AJAX apps

Strongly disagree.

I'm in the middle of a massive CakePHP/ExtJS development and it works
like a dream (To date: 40 controllers, 89 models). A lot of our
controller actions simply return JSON. Cake is perfectly suited to
this. Grab your data, do some set::extract manipulation on it if
necessary, and use the object method of the javascript helper to send
it to the client as JSON.

Also you should ALWAYS validate your data on the server side. Client
side validation is not reliable or secure. You can add it in as a
slight convenience to the user, but your application should never ever
rely on client side validation to do its job.

The technique we're currently using is we load Cake's forms into ExtJS
panels that proceed to digest the DOM elements (configure the form in
Ext, set the contentEl properties of the different panels to the ids
of the divs or fieldsets generated by cake) and then submit them via
AJAX back to the server. When the panel comes back, it has Cake's
validation messages next to the appropriate fields. This technique
also allows us to leverage the added security of the Security
component to ensure that no one's using Firebug or something similar
to allow them to submit data they aren't supposed to (which is a major
security risk a lot of developers in the honeymoon phase with AJAX
overlook or ignore).

We're also in the process of developing an ExtJS Form Helper that will
translate Cake's built-in validation rules to client side equivalents
to further tighten up the client-side experience.

Another thing people commonly misunderstand about MVC - or at least
take too literally - is the idea that each controller has to operate
on a single model. I reject that notion entirely - we organize our
controllers by logical functionality. For instance, we have a
controller that deals entirely with account related operations. We
don't have a table called accounts, and that controller operates on
half a dozen models. This makes the URLs more logical for the end-user
and it's much easier to maintain from a developer's standpoint, AND
makes it easier to divide up work amongst a team of developers.

Like Nate mentioned, this is not an MVC problem at all, just an
integration problem.

I hope to share a lot of the knowledge we've gained developing this
application on the Bakery at some point.

Good luck,
James

On Nov 30, 9:00 am, wirtsi <florian.kra...@googlemail.com> wrote:
> Hey guys
>
> I've been developing web applications with Cake for almost 2 years
> and  I never want go back to the old vile php ways again.
>
> I must say that with more advanced applications the MVC concept isn't
> working so good any more. With any halfway decent webapp you will have
> a lot of controller logic in the views, namely all those JavaScript
> functions you use.
>
> For example: Passing form field values to the server via ajax calls
> for validation or opening modal windows over content items (ie context
> menus etc)
>
> If you take JavaScript even a step further then you'll end up with
> frameworks like ExtJS ... you don't write a single line of HTML code
> anymore, just the body. The framework then will insert all the lists,
> menus or whatever you want onto the canvas and populate them with data
> it gets from the server via json.
>
> Working with Cake this gets really ugly .. because then you will end
> up with redundant code, data validation on the server side but also on
> the client.
>
> Yesterday I read an article on this issue (http://advogato.org/article/
> 993.html) ... it's a bit strong anti-PHP but it hits the spot. It goes
> on about combining a MVC framework (Web2Py) with a Python-to-
> Javascript compiler (Pyjamas) which in the end will result in coding
> in Python and having a framework do all the html work .. so like Ext
> but with a proper server-side backend.
>
> What also would solve the problem of code redundancy is a JS framework
> like TrimPath  (http://code.google.com/p/trimpath/wiki/TrimJunction)
> where you only code in JS and the same code gets executed on the
> server and the client ... BUT ... do we really want to code ours apps
> in JavaScript? I for sure don't want to.
>
> So I had this idea yesterday how to solve this problem at least
> partly .. by partly I mean at least all the data validation.
>
> Develop a doped up form helper. Said form helper gets the validation
> rules for every field from the model and implements the JavaScript
> rules automatically ... on the server side everything stays the same.
>
> For examle if field "name" has the NOT_EMPTY validation rule, the
> DopeFormHelper could add this validation to the view so even before
> submitting to the server the user gets notified of his mistake.
>
> What I'm not quite sure of is ... am I breaking all the MVC rules
> thinking like this? AFAIK the view (and therefore the Helper as well)
> should have no knowledge of any model rules or code. How do I get
> these informations in there?
>
> So what do the gurus think of this? Any ideas how to keep all that JS
> code out of our views?
>
> Enjoy your weekends
>
> wirtsi
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "CakePHP" group.
To post to this group, send email to cake-php@googlegroups.com
To unsubscribe from this group, send email to cake-php+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/cake-php?hl=en
-~----------~----~----~----~------~----~------~--~---

No comments: