Drawing on paper and establishing exactly how you want the site to look is a good indication
of what the database and business tier will contain (in other words, what functionality needs
to be supported by the User Interface, or UI).
Once the functional and technical specifications are done, you will know exactly what to
place in each tier, so the order in which you write the code doesn??™t matter. However, except for
the largest projects that really need very careful design and planning, this kind of flexibility
rarely happens in practice.
In this book, the usual way to start implementing a feature is with the lower levels (the database
and data object). In this chapter, however, we always start development with the presentation
tier, which you can now do because you already have a good overview of the architecture and can
foresee the implementation details of the business and data tiers. This knowledge is necessary,
because when implementing in the presentation tier, you will call methods from both of the other
CHAPTER 10 ?– CATALOG ADMINISTRATION: DEPARTMENTS AND CATEGORIES 285
tiers, neither of which you??™ve created. If you don??™t have a clear idea of how to implement all three
tiers, starting with the presentation tier would be a bad idea.
Implementing the Presentation Tier
Take another look at what the admin_departments componentized template looks like in action
(Figure 10-9 shows the componentized template running in Safari for Windows).
Pages:
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405