Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much

Re: Re: Re: Code Critique

by vladb (Vicar)
on Dec 19, 2001 at 21:37 UTC ( #133184=note: print w/replies, xml ) Need Help??

in reply to Re: Re: Code Critique
in thread Code Critique

I agree... discounting a few things that HTML::Template may be useful for, I always found it hard to actually 'wrap' my code around a template. I know that if separating code from content is an issue, then wouldn't it be simpler to move on to Mason? However, I'm not particular fan of this either since many Mason scripts I looked at appeared to be quite a mess.

Having said that, I am actually trying to move more towards splitting display logic from program logic. One way to do this, I think, would be to have your program generate and store all of its 'working' data mean to be displayed in some fashion in a hash or some complex enough structure which yet could be looped through/accessed via a templating script (such as <TMPL_LOOP ... > </TMPL_LOOP> implemented in HTML::Template).

Since I'm yet not a strong believer in Perl templating utilities, would anyone with some related experience share in his/her joys of using them? I'd be interested in hearing from someone who was in a position similar to I'm in now (that is 'hardly decided') and how they managed to integrate this concept in their code.

PS: my native language is Russian so don't mind my English! ;-)

"There is no system but GNU, and Linux is one of its kernels." -- Confession of Faith

Replies are listed 'Best First'.
Re: Re: Re: Re: Code Critique
by maverick (Curate) on Dec 19, 2001 at 23:13 UTC
    For small, personal projects or projects for which you are the 'display designer', the notion of using a template system seems like overkill. However if you ever get to the point of working on a larger project and having a dedicated 'display designer', you'll end up singing the praises of a template system.

    What if your development team consisted of 2 coders and 1 UI person? You might be decent at UI, the other coder isn't, and your UI guy really isn't that good at perl. Each of you needs to be able to exercise your strengths and not be hindered by your weaknesses.

    • What happens when the UI person needs to make a decent sized structural change to the HTML? There's a pretty big risk that he's going to break the program.
    • How many times is the UI guy going to be editing the same script (for UI changes) at the same time that you need to edit it for code changes?
    • Have you ever had to alter the flow of your logic to accomidate what the layout of the HTML has to be?
    • Can you imagine the horror if this UI guy wants to try and use something like DreamWeaver to edit the HTML? *shudder*
    • What if you're building an turn key type of website and the buyers all want a different UI?
    Ask yourself each of these questions with "If I have a templated system the answer is:" and "If I do not then it's:".

    Here's a real world scenerio. A site that I, another coder, and a UI guy developed uses HTML::Template and just underwent a complete UI change, along with adding features. The total number of pages is nearly 300. How many of the existing perl modules do you think had to be changed to accomidate any UI changes the designer made? In our case, none of them.

    perl -l -e "eval pack('h*','072796e6470272f2c5f2c5166756279636b672');"

      Agreed on every point! ;-).

      Maverick, since you've had earlier experience integrating a templating mechanism into your perl code (the backend for the site you've worked on), I'd like to repean an earlier question that I had. Did you have any difficulty integrating the templates? How did you overcome them? I'm really interested in knowing how you structured your display data so that it could be included within a template in any way the UI guy wanted to? Say, I had seen some complex templates with quite a bit of templating code.. how much of that did you have in your site?

      "There is no system but GNU, and Linux is one of its kernels." -- Confession of Faith
        Excellent questions.

        It is unfortunate that people tend to avoid answering this kind of question. The reason is that there are not simple good answers. But saying nothing can make pro-template people look a little religious. Templating is great for all of these reasons! Good luck getting any concrete advice on doing it though.

        The short answer is that templating is just a form of modularizing, and so you approach it like you would any other modularization. Define your division of labour into components. Define your interfaces. Then stick to them.

        Unfortunately that glib answer, while correct, is seriously misleading.

        Yes, templating is just another form of modularization. Modularization should, of course, be the bread and butter of any decent programmer. You should spend your days breaking problems up into components, defining interfaces to each component, then putting them together into programs. As is pointed out above, modularization with templating techniques is good for the various reasons that modularization is always good. It is a natural opportunity for modularizing because it allows you to divide tasks naturally along lines where the kinds of knowledge which are needed are very different. But it is unfortunately a hard place to modularize for many good reasons:

        1. We aren't as good at modularization as we could be.

          While modularization is good, in practice most programmers are somewhat inconsistent in doing it. We violate encapsulation, set up poorly chosen interfaces, don't get time to think about design, or may not even realize how much we don't understand program design. For most problems we can do all of this and mull through. But it means that when we need to modularize, the mental muscles you need to think through issues are not as well worked as you want them to be.

        2. It is also a language boundary.

          Modularizing is easier when both sides are the same language because interaction between them is more straightforward, and is likely to be the same on both sides. But in this case you are crossing a language boundary, and so interaction mechanics are different on each side. Plus the people on different sides are likely to be using radically different toolkits, making the difference even sharper. One set of interfaces just became two sets, that don't know how to talk directly. There are solutions, but what they are depend on your templating tool.

        3. There are different people on each side.

          It always complicates interactions hugely when you add to the mix the need for people with different ideas to cooperate.

        4. The two sides have different skillsets.

          When people with similar skills cooperate, they may disagree but it is at least relatively easy for one to explain the concerns they have to the other - the other has an experience base where they are likely to understand and figure out where to give and take. They might even offer good suggestions. Cooperating across a lack of common ground makes it harder to resolve issues.

        5. The other side is likely to have much less experience with modularization.

          As a programmer you are likely to think about modularization. In a lot of ways it is a big part of the mental toolkit through which you earn your bread and butter. The same is less likely to be true of the kind of graphics person who you may wind up interacting with on the other side. They learn how to use tools, how to achieve effects, and about how those effects affect people's reactions. They have less practice with, for instance, techniques for keeping changes synchronized across multiple places.

        That is quite a list of problems. And there isn't a single solution that I know of. Rather there are hard decisions, and how you need to make them depends on what you are doing. There are a range of solutions from generating HTML in code (eg CGI's autogeneration methods - easy for the programmer but makes it impossible for anyone who is not a programmer to work with it) to having the UI people using Dreamweaver with predefined components, some of which happen to be parametrized with callbacks to data sources programmers need to supply. I have used quite a few different solutions on this spectrum, and I strongly suspect that for any possibility I could find a situation in which I would choose to use it.

        But there are some principles that I think can guide people in figuring out how to handle this problem.

        • Pay attention to the trade-offs.

          When there isn't a general solution you can recommend pretty much across the board (I think there isn't), there usually are important trade-offs that need to be kept in mind. Templating is no exception. Templating is a level of indirection and complicates life for one or both (probably both) parties. You want the two to be able to work relatively independently with a minimum of getting in each other's way. There is, however, going to be set-up effort, limitations in how each side can work, and the infrastructure involves up front complications. What level of effort is acceptable depends on how complex the end task is, where the complexity is, what kinds of change requests are expected, and so on. Virtually the only choice you don't have here is whether you want to make them. You will need to make them.

        • Someone needs authority to make it work.

          Many of the issues I pointed out involve the need for cooperation between people with different needs and backgrounds. Unless someone is ready to say, No, you must play by the rules. it is guaranteed that people working at cross-purposes will accidentally undermine the necessary infrastructure. And the result will be a Big Ball of Mud.

        • The UI people need to be component aware.

          You asked how you structure things so that the data can go in in any way the UI person wants. Wrong question. In order to cooperate both sides must meet in the middle. Components that have programmatic data inputs take programmer effort to produce and customize. While the UI person may be able to place them, adjust various parameters in them (eg data source, colors, borders, etc), there will be inevitable limits. The programmers can offer black box components, and can work with the UI people to make sure that appropriate components are available, but components need to remain black if separation is to be maintained. (It is going, of course, to be much easier for everyone if the tools that the UI people use can be taught to understand the components which are available and work directly with them.)

        • There needs to be a clear division of types of control.

          If you are going to create a division of content and presentation, each type of thing needs to clearly fall on one side or the other. Look at this site for instance. Navigation is clearly controlled programmatically. Layout of nodelets likewise. UI people can create images, create new themes, create layout for new nodelets etc. But you could not just create a few new pages in Dreamweaver with a custom look and feel, drop them into the site, and have things go smoothly.

          That is a reasonable choice for a simple content-driven site. If you had more types of pages to offer and the content was less important, then you might want to let the UI people control overall layout much more freely. Whatever choice you make, initial choices here are going to drive the kinds of interfaces each side has to live with, which is going to decide what kinds of restrictions each lives with.

        • Keep your interface clean.

          As stated in my glib answer, this is fundamentally a modularization problem, and the answer is to proceed as you always do with modularization - define a division, define an interface across that division, and program to that interface. That is still, despite all of the additional problems and complications, fundamentally correct. And the key, as always with modularization, lies in defining a clean interface. The additional issues make that harder, which means keeping that in mind becomes more important, not less.

        A bit late, a lot long, but hopefully this answer will be helpful whenever you try to use templating. (I fear it will be most useful when you are trying to figure out why your first attempt didn't turn out as well as you wanted. But that helps your second attempt, so that is officially OK.)
      Firstly I'm a graphic designer by trade and only over the last six months have a started programming in perl, so this has always been a major gripe of mine.

      I agree with all but one of mavericks points. I use dreamweaver every day and I love it. Yes I can live without out it but when you are working to a deadline it produces clean code quickly.

      The use of a html templating system shouldn't be restricted to large sites.

      YESTERDAY: I wrote a site the other day that has a set of 30 thumbnails with large versions plus 8 normal pages. Rather than make 30 pages I wrote a script to look for the image name plus '_lrg.jpg'. Then a regex later and it dumps the image into my existing dreamweaver template and pipes that to display.
      TODAY: After a phone call I added a page to the site and only had to add one link in the template.
Embeded Perl
by IlyaM (Parson) on Dec 20, 2001 at 00:45 UTC
    I know that if separating code from content is an issue, then wouldn't it be simpler to move on to Mason? However, I'm not particular fan of this either since many Mason scripts I looked at appeared to be quite a mess.

    With embeded Perl it is very easy to write HTML/Perl pages which look like a mess. It requires some self-dicpline to control use of Perl in templates. But it is possible to do it in right way (put business logic in modules, use Perl code in templates only to produce output, separate big sections of Perl and HTML). There exist quite good examples of HTML::Mason code: sources of, sources of Request Tracker.

    Ilya Martynov (

      My try was, as I didn't really like the existing alternatives. There'll be a new version soon.
      The thought behind it is quite simple: s/// the page into a CGI script and eval it ;) Works like a charm.

      2;0 juerd@ouranos:~$ perl -e'undef christmas' Segmentation fault 2;139 juerd@ouranos:~$

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://133184]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others pondering the Monastery: (8)
As of 2020-10-01 08:49 GMT
Find Nodes?
    Voting Booth?
    If at first I donít succeed, I Ö

    Results (177 votes). Check out past polls.