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, | [reply] [Watch: Dir/Any] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(jeffa) Re: XSL/XML/Perl as a development process
by jeffa (Bishop) on Jun 15, 2003 at 14:31 UTC | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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) | [reply] [Watch: Dir/Any] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
by chunlou (Curate) on Jun 15, 2003 at 17:24 UTC | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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. | [reply] [Watch: Dir/Any] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
by zby (Vicar) on Jun 16, 2003 at 09:50 UTC | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| [reply] [Watch: Dir/Any] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
by chunlou (Curate) on Jun 15, 2003 at 17:47 UTC | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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. | [reply] [Watch: Dir/Any] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Re: XSL/XML/Perl as a development process
by weierophinney (Pilgrim) on Jun 15, 2003 at 19:50 UTC | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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. | [reply] [Watch: Dir/Any] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
by chunlou (Curate) on Jun 15, 2003 at 22:37 UTC | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
I rarely have such a "good manager." Examples of spec from the managers could be like:
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. | [reply] [Watch: Dir/Any] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
by chunlou (Curate) on Jun 16, 2003 at 23:04 UTC | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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
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. | [reply] [Watch: Dir/Any] |