Welcome Guest, Not a member yet? Register   Sign In
Sanity check: My development workflow
#1

[eluser]mtbkrdave[/eluser]
Hi Y'all-

I'm working on a public-intent beta for my CI app, and I'm trying to use coding practices that reflect the way I'll approach my final version as much as possible.

I've finished mapping out my controllers and functions according to the site's features and pages, and I've got all the controllers stubbed out. That activity alone caught a lot of 'gotchas' in my planning! Now that I'm ready to write some actual code, I'm struggling with where to start. Here's the approach I've whomped up:

1) Write the views first. For all but the simplest controller<--&gt;view relationships, hard-code the dynamic data right into the view, but clearly identify (using HTML comments) all the areas that depend on dynamic data.

2) Once I've got the views rendering right, write controllers that deliver the flagged data in the views, and modify the views to display what's passed instead of hard-coded values. In lieu of database queries, use statically-defined data in the controllers (or load from a constants file) to ring out the controller<--&gt;view interface.

3) Write models to deliver the same static data to the controllers, building up the model<--&gt;controller interface without worrying about what's going on under the hood of the models.

4) Finally, after the models and controllers are playing nice, write the guts of the models and replace the static data with database queries.

Does this seem like a reasonable approach? Would you approach it differently?

A couple of resulting questions:

A) Is there any way for a model to echo out debug data? Can models write entries out through the CI logging system? Or could a model open up its own log file in an application-specific log directory somewhere on the path?

B) Without actually performing a database query, how can I mimic the behavior of the $this->query->result() function? I took a look into db_result.php but immediately soiled myself!

Thanks all!
[medic]Dave
#2

[eluser]missionsix[/eluser]
Hmm interesting.

Seems like your doing a top > down approach here. The problem i see with this is that once you modify something in the next layer, your might have to step back up a layer to make changes.

I prefer writing from the ground up. Plan my database structure first. And then build my models on top of the database. Once the models are written, i can use them properly in my controller. At which point I would build up the controllers based on a pre-determined site structure.

I kind of do the views / controllers at the same time, building the needed parts as i put together a page.


But yeah, i like your approach as well. Whatever works best for you is what matters.
#3

[eluser]crumpet[/eluser]
i have to agree with missionsix
i would definitely start with the model and then go to the controller and then the view
you can change your view however you want and it doesn't make any difference to the model and controller if you have programmed them well.. the model however you cannot change or you have to change all other parts of the app
#4

[eluser]jalalski[/eluser]
If you have a very clear idea of what your data structures are, then start with the model (i.e. a Contact Manager) but if your ideas and concept are based around the use cases (the functionality, say for a CMS) then you will want to start with the screens. In most cases I would start with the model, even use a UML or DB modeller for this stage.

Whatever, the core of your app will be in the Controllers, this is where your 'business logic' resides and I make it a practise to put a lot of thought into what goes on there. In general, I try to move all business logic out of the Views and Models and into the Controllers.

In regard to your questions:
A) a first question is why does your model need to output debug? I generally handle that in the Controller with whatever is generated by the Model. The data coming out of the model should be correct. If you're having trouble debugging queries, then I sometimes put a wrong table name and then the system dumps out the query for me so that I can see how it ended up.
B) query->result() returns an array, so you could just hard code an array and use that?

HTH
#5

[eluser]mtbkrdave[/eluser]
Hi Guys - Thank You for the feedback!

I guess the view--&gt;controller--&gt;model approach made the most sense to me initially because I'm not quite sure which models I'm going to need yet (though I do have the database schema designed) but I do know what each rendered page should look like. Kind of like Doug Bowman's take on CSS implementation: design your page first, even if it's just with pencil and paper, and only start implementing once you know what you're trying to achieve (i.e. if you try to do visual design by writing CSS, you'll tear your hair out).

I can, however, see the value in going model--&gt;controller--&gt;view, too - especially with a clear idea of what the data objects will look like. Given that the model is typically going to return array data keyed by the column names within each table, using the wrong name [in my suggested workflow] at the view level could propagate all the way back through the controller to the model before the error is discovered.

As for the questions...

A) I'd like to be able to get raw debug info out of the model functions because some of my models will need to do some geospatial calculations before they hit the database, and others will rely on calls to remote geocoding/reverse-geocoding services. Getting a look at the inner workings of the model (while it's being debugged) would be useful without having to alter the organization of the returned data and how the controller handles it.

B) I think I messed up my question. I guess what I should have said was: if I wanted to build myself a $query object without using the active record class (i.e. to hold the static stub data), how would I craft the return() function within that object so that it plays nice with foreach()? Should I just quit making this so bloody complicated and scaffold up some database rows?? Smile

Thanks,
[medic]Dave
#6

[eluser]Teks[/eluser]
@medicdave: my experience has been, that in small projects, it does not really matter which development approach you take. As projects get larger and more complex, it becomes increasingly important to have a work methodology. Unfortunately, over the last 30 years or so, there has been an endless procession of software engineering 'methodologies' and fads - ie., 'linear', 'cascade', 'iterative', 'spiral', 'test-driven', etc. - each promising to be a better solution than the one before, and supposedly helping us work better, faster, and more effectively. I confess, that I myself have wasted *far* too much of my good work hours 'experimenting' with new approaches, and judiciously documenting the results for my own benefit.

I have come to the conclusion, that even with large, complex projects, the approach that is the most productive for me is:

1) in the REQUIREMENTS stage of the project, while people are still defining what the software (or site) should do, a top-down approach - like what you have just done - is by far the best. Concentrate on the interface, and the functionality, from the END USER perspective. Try not to think about how things will work behind the scenes - that can be defined later. At the end of this stage, you should have not only a usable list of requirements, but also some good 'roughs' of the entire interface.

2) in the DESIGN (and IMPLEMENTATION) stages, without a shadow of a doubt, the bottom-up approach is quicker: define what DATA your application/site will need to maintain/store, create the database, and model classes. Your controllers follow next, and as you develop these, the required views will naturally follow. I have found that for programmers new to the MVC design pattern, the bottom-up approach helps them clarify what functionality should be at what level. Newbie programmers using a top-down approach usually results in views that deal directly with accessing data.

3) test all the time, and do make ample use of TESTING features, if the framework you are using has those. CodeIgniter has the Unit Testing class, which although basic, can already save you much headache and trouble. As you develop functions for your models, for instance, develop also tests at the same time - and run the tests often, ensuring that after every bit of functionality you add, nothing old has broken.

Last of all, the larger the project, the more 'iterations' of the development process I need to make. For a simple, straight-forward site, I often only need one requirement/design/implementation/deployment stage. In larger projects, however, after each implementation stage I usually go back to the client, re-evaluate the requirements, and make alterations to the design and implementation as needed. This means, that on very large projects, requirements my get between 3 to 5 revisions, on average - and I don't mind at all, since the client ends up happier, with a much more polished product, and I am entitled to bill for more hours.

I hope this helps.
#7

[eluser]mtbkrdave[/eluser]
Teks - Thanks very much for diving into this for me; your post is indeed very helpful!

Maybe my lack of a good sense of what models are needed stems from insufficiently-defined project requirements. I write requirements for a living (though for electronics, not web sites) so I'm well-versed in the methodologies there; I'd consciously kept my requirements documentation on the light (though not non-existent) side since (on this project) the same person (me) is both identifying the requirements and implementing. Might have to take that up a notch...

Thanks again!
[medic]Dave
#8

[eluser]1stInter[/eluser]
Hi,

I completely agree with Teks - getting the user side specified and designed first as a prototype is invaluable. Clients have often told me: "Didn't realise it would look like that, I also need... And I don't want..." etc. Saves a lot of time and the client is much happier when you get things looking the way they want it early on.

Also, psychologically, you can show the client progress early in the process so they are happy things are happening. If they like looking over your shoulder you can then provide frequent updates by showing them functionality coming "alive" during the development.

What I really wanted to say, was about debugging. Look into FirePHP. It's brilliant because it allows you to see all the debugging information you want without changing anything in your screen layout.

Regards,
Steve




Theme © iAndrew 2016 - Forum software by © MyBB