in reply to Re: Re: One structure to describe multiple arrays or hashes
in thread One structure to describe multiple arrays or hashes

Yes, it does, and the authors specifically state that having the template do all the heavy lifting violates standard practice for large applications. However, they do state that, for smaller sites, this can be beneficial.

In addition, having your templates talk to a database doesn't violate MVC, in and of itself. Let's take a real-world example that I have worked on - a site that is available in 12 languages. Obviously, what language you present in is a V-layer issue. So, when you want to specify the column names for your report, you indicate in your code (either in the template or in the script) that you want the names for column 1 .. 5 in language $lang. The template would then lookup in a front-end database what the actual strings are for those columns in that language.

Contrast this approach with the one that was taken. They were using HTML::Template, not Template Toolkit. They had a master template with the column specifiers. They then had a pre-processing step (kinda like compiling templates) which converted the master into 12 copies, one for each language. The actual strings were stored in a database that would be consulted when the templates were compiled.

I know which method I prefer ...

------
We are the carpenters and bricklayers of the Information Age.

Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

  • Comment on Re: Re: Re: One structure to describe multiple arrays or hashes

Replies are listed 'Best First'.
Re: Re: Re: Re: One structure to describe multiple arrays or hashes
by exussum0 (Vicar) on Apr 28, 2004 at 15:08 UTC
    In addition, having your templates talk to a database doesn't violate MVC, in and of itself.
    Yes it does. Should one layer change, the other will have to change. You should have some conduit/api where one talks to the other, such as a function or something. And that usually does not include putting DB stuff directly in your templates... unless you can show me an example where I'm misunderstanding your meaning. :)
    Let's take a real-world example that I have worked on - a site that is available in 12 languages. Obviously, what language you present in is a V-layer issue. So, when you want to specify the column names for your report, you indicate in your code (either in the template or in the script) that you want the names for column 1 .. 5 in language $lang. The template would then lookup in a front-end database what the actual strings are for those columns in that language.
    I rather the second oddly enough, but not have column names tored in the database. Use a properties file for that, and internally assemble them as template variables. But you know what, in the end, the devil is in the details of the technolgoies you are using.

    The reason I'm used to not putting things like, display stuff in the database, particularly column headers, if that's what you mean, is because the technology I use for populating them into HTML, is the same one i use for email/smtp and desktop applications.

    But this is all religon, we can argue for days. :)

    Humma la beeba la seeba la booba la
    Humma la beeba la seeba la bop
[reply]
      There comes a point where one is adding layers solely to comply with an Ivory Tower concept. Having a database instance whose only function is to provide storage for V-layer data makes a lot of sense to me. Have the V-layer talk to that database also makes sense to me. Otherwise, you have the C-layer talking to a V-layer datastore. That is a greater violation of MVC than having the V-layer talk to its datastore.

      The issue here is that most developers see the word database and automatically think M-layer. All databases aren't M-layer. For example, where do you place the front-end database that stores sessioning information? That's C-layer, to me.

      ------
      We are the carpenters and bricklayers of the Information Age.

      Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

[reply]

In Section Meditations