http://www.perlmonks.org?node_id=265998

Considered: liz root node seems to have lost its content? Restore?
Unconsidered: castaway Keep/Edit/Delete: 1/20/2 - unfortunately neither thepen nor the NNTP server have a copy of the original content.

Replies are listed 'Best First'.
Re: XSL/XML/Perl as a development process
by Zaxo (Archbishop) on Jun 15, 2003 at 05:44 UTC

    ++ for the thought and effort, this is an admirable decomposition of web development.

    If only it was attainable. The manager, designer, or both are going to demand something that is utterly irresponsible to give them. It may be an open mail relay ("I can get that from Matt's Script Archive, why can't you do it? What do I need you for!"), a free shell account dispenser, or a convenient ftp upload site with public access. They have the power of the purse, so your warnings indicate the kind of commercial cowardace that consigned you to peonage in the first place.

    Try to obtain contracts where the managers go lightly and the designers can remember ASC mode of ftp. Make sure the managers wishes are approved by, and can be vetoed by, competent sysadmins on their host.

    After Compline,
    Zaxo

(jeffa) Re: XSL/XML/Perl as a development process
by jeffa (Bishop) on Jun 15, 2003 at 14:31 UTC
    Nice post (but do we really need the CSS?). Question: why is the XML file static? I myself have used static XML files before (if i need a new record, i add one by hand via vim), but in 'real world', that data is stored in a relation database. If you had used XML::Generator::DBI, then i could see the point better, but having the "boss" handle the XML file seems, wrong.

    Also, i feel compelled to mention that unless you are looking for platform independence, XML/XSLT just isn't as fun as a pure Perl templating solution, such as HTML::Template or Template, IMHO. I really think this would have been a better article if you had included them as well. But effort++. :)

    Addendum: indeed, i really wish you had made this article more general, as what you are describing is the model view control "pattern".

    jeffa

    L-LL-L--L-LL-L--L-LL-L--
    -R--R-RR-R--R-RR-R--R-RR
    B--B--B--B--B--B--B--B--
    H---H---H---H---H---H---
    (the triplet paradiddle with high-hat)
    
      CSS       Right, it wouldn't lose much for the discussion even should the CSS not included. It's just more complete as an example with one.

      STATIC XML       The static XML file is for the Artist (or Web/Frontend Designer) to be able to do the HTML markup with XSL without the Perl script even ready.

      The static XML also serves as a req spec doc. In a working app, you probably won't have or need a static XML file sitting around. The XML will be generated dynamically from within a Perl script by then. But during the devel proc, it's good to have a static XML file against which to check your Perl's generated XML.

      BOSS       Sorry for not explaining the BOSS-XML part. A BOSS could be your Project Manager or System Analyst or Team Leader. Or, to read that relation another way, a BOSS-Client conveyed a req to your Project Manager to your Lead Programmer who came up with the XML.

      No, a non-techie BOSS handling XML won't be a good idea.

      HTML::Template       Template is really a clean solution. Easy to use. It does the job of separating Perl and HTML. Especially nice when the same person who does both the HTML and the Perl. Not to hard for less technical Web designer to handle a Template either.

      However, sometimes (or most of the times) a Template need to wait for a Perl script in order to see the complete HTML result. Hence, lacks the independency. XSL can check it against a static XML, not Perl script.

      Also, when changes were made to both Template and Perl script simultaneously and something went wrong, you might need to check a Template and a Perl script against each other--an a bit more troublesome debugging process--whereas (in theory) XSL and Perl script check against XML (which is supposed to be locked/frozen).

      Yet another situation, you need output to multiple media. A common req is that a client wants a report to be on the Web, as well as on PDF. (Well, refer to your phone bill, for example.) XSL makes a sensible solution, though I won't claim it's the best.

      One more thing, you can't swap your "backend" (the Perl script) with Template. XSL doesn't care what backend you use.

      Of course, if those are not your concerns, HTML::Template makes a good choice.

      XML/XSLT NOT FUN       I must say, XML does require more discipline than many Web development companies are willing to commit to. (Many organizations tried to come up with some XML templates and ended up nowhere.) No, XML/XSLT isn't fun. Neither is trying to make a "quick fix" to a live system, just because some client/account manager forgot some "minor" req.

      The point is not so much about using XML as it's about thinking things through. It's a mixed blessing that you don't need much planning to code a PHP page, for instance. XML forces you to do a bit more thinking.

      A FOOTNOTE       Actually, to be more correct or "orthodox," when I said checking a Perl script's XML result against XML, I probably should or could have said DTD or Schema, in lieu of XML. But not everyone bothers with DTD or Schema. XML alone is an enough start.
        You can use templating with XPath expressions (this is possible with Template::Toolkit - don't know how about other templating libraries). This way the templates could be used with static XML. So at least the XSLT part can be replaced.
      I didn't usually find "general" theory as a first lecture worked pedagogically. I found people learnt better with concrete examples.

      Most people (if not all) learnt arithematic before learning set theory (if they ever did). And most CS students (if not all) learnt Pascal or Java or BASIC first, not lambda-calculus.

      But then, I also always adjust my presentation to suit the audience.
Re: XSL/XML/Perl as a development process
by weierophinney (Pilgrim) on Jun 15, 2003 at 19:50 UTC
    While I find this interesting, the idea is hardly new: separate the content (usually generated by scripts the programmer writes) from the layout/markup (generated by an "artist" or designer). Much of this today can be achieved with or without XML/XSL by using (X)HTML + CSS with a good backend process for generating content (perl, of course!). Good programmer/designers do this, and good production houses already separate the jobs.

    I also feel that a good manager will develop a decent specification that will tell (1) the artist/designer what needs to be on the various pages of a site, including types of content and general layout guidelines, and (2) the programmer what sorts of data need to be consumed and the general output that should be thrown to the layout. If this is done correctly, your "XML as Wall of Separation" argument shouldn't need to be raised at all.

    I *do* like your table regarding "Who Do What"; it clearly and cleanly shows that architectural changes to a site affect *everybody* and not just the programmer OR artist. This is too often forgotten.

      The problem is not finding new ideas of devel proc but executing any old concept descently.

      I rarely have such a "good manager." Examples of spec from the managers could be like:
      • "Make it look sexy"
      • "Make it flexible"--euphemism for 'I duno what I'm doing'
      • "Just turn the paper forms into webpages"--when building an employee performance evaluation application
      • "Use a 3D spider web display"--for an org chart--2D info
      • "This is exactly what the client wanted!"--no, it wasn't, since we redid the entire project afterwards.
      I think I should clarify role-and-responsibility a little bit at this point:
       

      Devel Phase

      Role1. Req Elicit./Analysis:
      What to Do
      Design:
      How to Do
      Coding:
      Do
      Testing:
      Done (hopefully)
      Mgr/Client lead     verify
      Proj Mgr/Sys Analyst lead lead buffer
      disturbance
      coordinate
      Artist/Programmer (as needed) lead lead fix
      QA (as needed) lead   lead
      Artifacts: flowcharts,
      screenshots,
      use cases...
      DB schema,
      class diagram,
      site map,
      (prelim) test script2....
      (you know
      what...)
      results to the
      test matrix...

      1.Note that a single person could take multiple roles.
      2. Not everyone writes a test script during Design. But having one could provide insight. Say, if a test script gets too complicated, probably so is the app.

      It is not usually a good idea for an business manager to tell programmers what to do directly. Two reasons:

      One, doing so is like a patient (the biz mgr) telling a doc (the programmer) what drug and treatment he (the patient) should take.

      Two, if one biz mgr can do it, any of them can. Hence, conflict of interests. Everyone wants their jobs done first. Besides, changes become intractable.

      Normally, during Req Elicitation, a Client or Mgr would be like a patient, a Proj Mgr (or Sys Analyst) plays the role of clinical psychologist, literally. It really takes a skillset of a clinical psychologist to do Req Elicitation well. That's why (for me), a good personnel in that role is the most difficult to find.

      Unfortunately, Req Elicitation is often the most poorly done. Thus, the tragedy--a bad and wrong biz idea perfectly implemented--which is still a bad and wrong biz idea.
        Thought I should round up my answer more even-handedly.

        In practice, I feel managers and programmers (or any "technical" personnel) are as much a victim as vilain, since most of them were never taught how to work with each other.

        The CS curriculum normally focuses on programming, nothing much on how to work with people. (Like, a programmer might always complain a req spec wasn't "perfect," instead of helping a non-techie how to write a spec.)

        A biz program teaches quite a bit of concepts and theories, but not every biz student came out with good implemenation knowledge (theoretical or pragmatic). I usually found them lack of any concept of "stable system" and why you can't meaningful fix and improve a system that's not "stable." Instead, management by crisis or mgt by (annoying) cheerleading is a common style, which often amounts to destablizing a system.

        It would be better if mgrs and programmers have overlapping knowledge that helps bridge their communication gap. In an ideal world, we could have the following:

        Stylized view of the distribution of knowledge and skill sets
         

        knowledge\skill sets

          strategic
        thinking
        biz
        sense
        req elicit
        (aka mind-
        reading?)
        req
        analysis
         design programming  QA
        (conceptual
        and/or
        technical)
        biz/acc't mgr
         
          
         
          
         
          
         
          
         
          
         
          
         
          
        proj mgr
         
          
         
          
         
          
         
          
         
          
         
          
         
          
        sys analyst1.
         
          
         
          
         
          
         
          
         
          
         
          
         
          
        lead programmer1.
         
          
         
          
         
          
         
          
         
          
         
          
         
          
        programmer
         
          
         
          
         
          
         
          
         
          
         
          
         
          
        what to
        do/know:
        if a project/client
        strategically or
        technologically
        compatible &
        complementing
        the current sys
        or products...
        how a project
        contributes to
        the bottomline,
        or to the
        current system
        or products...
        ask questions
        that lead to
        actionable
        requirements...
        if each step
        has adequate
        input-output
        params,
        generalize/
        minimize
        the flowchart...
        generalize,
        minimize...
        (assume
        you know
        best here)
        explain to
        mgr why
        the one who
        programmed
        shouldn't be
        the one
        who tests...
        sample
        artifacts:
        a sensible
        executive
        talks sensibly...
        biz case,
        justifies proj ...
        flowchart
        (readable by
        clients
        ) w/
        indications of
        input-output
        params at
        each step...
        flowchart
        (meaningful to
        programmers
        ),
        conceptual
        class
        diagram...
        class
        diagram,
        activity
        diagram,
        mock
        screens...
        (assume
        you know
        best here)
        test scripts
        (manual or
        automated)

        1.sys analyst -- system-wide architectural issues
          lead programmer -- individual applications


        If people don't come in readily with what it takes, we just have to train them in house (if feasible).

        See that, on one hand, the major reasons of the software projects' failure (as a business) are "managerial," rather than "technical;" on the other hand, managerial decision process is a collective effort, not just by titled managers.