wirtsi,
I honestly think you're takoing the wrong approach here.
For example: emdedding alert() calls in your models??? How fragile a
system will that create? How will you use your business logic in CRON
jobs/ other contexts? I know progressive enhancement has its own
issues, but I think it's much better than the system you seem to have
in mind.
For example, I often use JQuery to do stuff like this:
- standard cake form on the page
- hijack it with JQ to do an ajax submit
- parse the results in JQ (real easy) and insert field/validation
messages into the page dynamically
You can take this further and (as per James K's very good response)
ask for different outputs depending upon the extension -
i.e add .json to the form action URLs so they return data easily used
by JS.
Advantages of this approach are numerous: your site can still work
without JS, is more secure, is reliable cross-platform, with less
coupling, you can keep your JS code in .js files (where it belongs)
and there are SEO benefits!
I know that there are issues with the way important business logic is
spread throughout the server and client layers, but I don't think this
is a MVC issue specifically - it's just the cost of pushing the
boundaries of web apps. And as James mentioned, you'll always need a
foundation of server side code for security etc, and trust me, always
having a working mechanism for your users (even as a backup) in case
your javascript doesn't work in their environment is a big advantage.
Imho, you should try and push the progressive enhancement / separation
of concerns as far as you can before you consider opting for
integrating the client side code with your business logic...
Sorry for the long response, but it appears I have quite strong
feelings on the subject :)
On Nov 30, 4:47 pm, wirtsi <[EMAIL PROTECTED]> wrote:
> James, that ExtHelper of yours would truly be very interesting to
> me ... I've been wrapping my head around Ext the last few weeks and I
> really like the possibilities it gives you creating spot on user
> interfaces .. I just found it a massive pain to get the data over from
> Cake, especially with 1:n or n:m relationships which I more or less
> had to put back together by hand in ext (because I had to flatten the
> data output list to one level) but then perhaps I haven't quite
> grasped all that DataReader stuff yet.
>
> I really like the idea just using a form submit to validate the
> data ... I was thinking along the lines of per field ajax submit &
> validate (like you see in the ext demos .. field is empty, ext
> complains about it right away) but what the heck, this seems so much
> easier :). Do you validate only after a user submits (via ajax) or do
> you submit periodically to display errors on the fly? In latter case I
> could image one could get quite a few duplicate entries if the user
> happens to fill out all the fields correctly.
>
> But to get back to my original post, how would it sound if Cake
> allowed for user defined JavaScript functions in the model definition.
> For example "name" NOT_EMPTY but also "alert('Must not be empty') so
> the server checks the field on submit (in case anyone was fiddling
> around with the post data) but the javascript function gets pushed
> through to the view.
>
> Ok, that would be having view code in the model but on the other hand
> this code is definitely related to the models data.
>
> Thanks for your input
>
> wirtsi
>
> On 30 Nov., 16:07, James K <[EMAIL PROTECTED]> wrote:
>
> > 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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/cake-php?hl=en
-~----------~----~----~----~------~----~------~--~---
