Page 3 of 3

Re: CRUD controllers

Posted: Sun Aug 09, 2009 1:52 am
by josh
pytrin wrote:I'm not really getting you. Yes, I am checking for POST submission in the controller but that method is part of the API (of the controller). The validation is part of the Model's API. Both are abstracted away - and are resued within the controller. So what are the cons in that?
Yeah they're abstracted which puts you in the 99% percentile of good apps out there in my opinion!

I'm just saying the actual process of checking for a post request, asking the model to validate, pushing errors to the view is a repeating sequence, that very realistically may need to be maintained in the future. Although if you have only a few K of controller code I don't see 10 lines of duplication being a big deal, but it is duplication that can be very easily avoided. The good part about OO is you can refactor it later, "just in time" ( when you start feeling the pains of doing it the linear way, in my opinion which you will eventually one day on one project )

Also you won't have all your controllers abstracted, there are going to be some oddballs that have to completely override the whole action

Re: CRUD controllers

Posted: Sun Aug 09, 2009 3:38 am
by Eran
Did you ever encounter the need to change all the edit / create / list actions of your project in one place? such a use-case might help me see your point

Re: CRUD controllers

Posted: Sun Aug 09, 2009 12:39 pm
by josh
Yes, lots of places as discussed. For instance we had a form control that allowed editing via ajax, needed behavior modified for all our editActions to be able to return a JSON of the edited object and a status code rather then a human readable success message.

Another was adding a feature "save and continue" to allow the user to keep adding new records rather then being redirected back to the index. Some applications provide the choice for the user to "go back insert another record", or multiple other options. Then a week later the client removed that feature meaning we had to update it all again

These changes can either take 5 minutes or 5 hours depending on how many places it needs to be changed. With the ajax thing we had to pull back the errors in a json object. Another thing I wanted to add a delete button which required passing the model's id to the view, I've had cases where I needed to pass the model being edited to the view as well in addition to the form & id.

On the delete action I went from deleting 1 record to allowing multiple, another change was pushing a collection of models to the view so we could render their __toString() so the user knows what theyre deleting, or the ability to reprompt the user to assign child records to a new parent when deleting the current parent.

On my index listing I added faceted search and text filters that allow searching "within" the current results or "all" results, only required modifying getModels() on the abstract controller to pass the activated filters to my data mapper.

ANother similar requirement is different types of security assertions, like asserting the user owns the record before continuing editing, things like that.... there are lots of reasons it could need to change.

Ask yourself this, if you wanted to make your whole application run on the command line, how many lines of code are coupled to the concept of http? ->isPost() would always return false on a command line. If its in 5-10 controllers its probably not going to cause you any trouble but like I said some of us have to work on larger apps with potentially 100s of screens that change every week

Re: CRUD controllers

Posted: Sun Aug 09, 2009 2:31 pm
by Eran
needed behavior modified for all our editActions to be able to return a JSON
ALL of your editActions? I assume you had to update the corresponding views as well. To me it seems unlikely that such a huge change in the application would happen and am willing to take the hit. This is similar to writing completely database unaware code, disregarding brand specific optimizations. I use database abstractions of course, but I do use caveats for my particular brand and engine (MySQL / InnoDB)
Another was adding a feature "save and continue" to allow the user to keep adding new records rather then being redirected back to the index
This was for ALL of your editActions as well?
Ask yourself this, if you wanted to make your whole application run on the command line, how many lines of code are coupled to the concept of http? ->isPost() would always return false on a command
Running a http controllers from the command line is not something I strive for. I can run my models from anywhere, but my controllers have to be aware of the format of the data somehow. In the off change that would happen, I could change how isPost works. But again, I don't see that happening
I said some of us have to work on larger apps
I've worked on very large apps, spearheading multiple developers. I'm not sure if you meant it, but it sounded somewhat condescending.
So far my approach has proven itself to me in speeding development efforts, reducing complexity and and improving maintainability. 100s of screens change every week? all through the controller and in the same manner? that sounds like something is off in the specification / requirements / feedback process.

As I've said, your approach can work but it has its issues and from my experience I rather deal with concrete controllers. I assure you that it can work as well, and for very large apps.

Re: CRUD controllers

Posted: Sun Aug 09, 2009 4:52 pm
by josh
No intention to come of condescending. And yeah 100s of screens that all use consistent layouts, styling, functionality. And no I didnt have to update my views ;-) in my views I call up a model specific sub-form for the form's controls, so I call up Some_Model_Controls_Edit or Some_Model_Controls_New, all the controls in my app share the same super class and get passed an instance of the model being edited ( if its the edit controls ) so it can get add accessors for generating URLs, etc.. All the layout is done thru decorators and / or style sheets, some controls sub-forms have different buttons because different models have different actions you can take on them, etc..

Updating the screens that often happens when you are really really paranoid about usability

Re: CRUD controllers

Posted: Tue Sep 22, 2009 9:52 pm
by josh