Re: Somewhat Dynamic HTML
Re: Somewhat Dynamic HTML
- Subject: Re: Somewhat Dynamic HTML
- From: has <email@hidden>
- Date: Fri, 8 Mar 2002 12:55:41 +0000
Andy Wylie wrote:
>
I'd use the stout combo of Smile and Akua for the whole job, free and AS.
Akua may prove prolematic however if you intend to move to OS X any time
soon. I used to be pretty big on it myself, but even though I doubt I'll
move to X any time soon I've already gotten into the habit of using
vanilla/SA code as much as possible.
>
I'm thinking an easy way may be to create the directory of images in folders
>
and parse it building a list of paired list or records...
>
{name:"SanFrancisco", imagePath:"" , formatted image tag:"" } etc
>
Save these records as resources using name string "California" in file
>
"West" of folder "Region" for a database and start the interface with a
>
Smilesheet template editor/script runner which can be refined to a dialog
>
later.
Well, that's your data structures and your GUI covered; now what about the
rendering code? ;)
Awww, ok. I'm pulling your leg a bit, I know, but it really comes down to
whether it's worth writing a renderer from scratch (which'll probably be
hardwired to that particular job) or learn and use an existing one.
WebMerge [the FMP-oriented app that I couldn't mind the name of before]
takes care of everything for you [the catch with it though is that it's
very limited in what it can do]. Frontier would [I imagine] save you from
having to do any/much of the hard stuff; you'd just need to add your own
code to hook those bits together (much like you might build a custom
Entourage<->FMP solution in AS).
--
Incidentally, the sort of list of records you describe above is just the
sort of thing that AWPS likes the most.
I actually wrote a second demo that does something very similar to this,
pulling files from disk and building pages from their contents. I won't
show it though because it runs *much* slower, making AWPS look bad. (Only,
when I checked I found this wasn't AWPS's fault at all; it was the damned
Finder[!]. Hopefully it'll run much better under OS X, but IMHO the classic
Finder is an absolute SLUG when it comes to scripting.)
--
[AWPS]
>
vanilla image tags? It's cool but I can't help thinking it may be an
>
exercise in futility doing it vanilla and that puts me off taking the time
>
to understand it and adapt it to my own needs, once I use Akua for anything
>
it doesn't make sense to do lots of other stuff vanilla anymore as I have
>
lots of new sharp tools and the code is usually smaller and easier for me.
AWPS may be vanilla [1] in itself, but it certainly doesn't force you to be
vanilla in your glue code: you can use whatever osaxen and/or 3rd-party
libraries you like there.
As for the size of AWPS... well, it's ~1700 lines of code, but the user
honestly doesn't need to know about *any* of that. All they need is a list
of its public handler/method calls and some instructions on how to use
them. And I'm sure anyone skilled enough to write their own template
renderer will also be able to read and understand AWPS's manual; and in
much less time.
But warning: I now feel a related lecture coming on... [Those of you tired
of the sound of my voice already can skip to the end now.;]
__Exercises In Futility 101__
The other thing about 3rd-party osaxen is that using them *doesn't
automatically* lead to better code. In the last CMS I wrote, I used Akua
and Regex Commands extensively to do all of the heavy lifting. I didn't
bother to plan in advance, since I knew all my problems could be solved
en-route by throwing an osax at them. Nor did I sit down and think if my
designs were as efficient as they could be, because everyone knows that
using osaxen makes scripts faster, right?
The code ended up being a massive, horrendously slow linguine-filled hole.
It worked, but that's the only good thing I can say about it. A month later
I took the entire codebase and killed and buried it in disgust.
Talk about "exercises in futility", eh? ;)
--
So I swore of osaxen for a couple months, and using only vanilla AS
literally forced me to learn how to design efficient algorithms, how to sit
down and plan projects in advance (top-down thinking) and how to write
readable, maintainable, structured code. In turn, I went on and learned OOP
as a way of managing complex data structures more easily; and finally
(after a couple false starts) I wrote AWPS. [2]
The real key to AWPS is that, having learned how to do efficient top-down
design, I realised the value of separating all the slow functionality from
the fast. Hence in AWPS the parsing and the rendering are two completely
separate functions (in my earlier attempt they were mixed).
It doesn't matter if it takes several seconds to parse an html template
because you'll only ever do that when you design a new template. The
renderer needs to be damn zippy though, because it will get used an awful
lot. As a result, AWPS's rendering code is _very_ simple and streamlined;
it simply doesn't require any 3rd-party osaxen to work.
_______________________
I'm not anti-osax, mind; it's just that I've learned not to solve every
problem by throwing an osax at it. It's too easy to make them a crutch for
lack of good design and coding practices.
And even though my code may be bigger, it's still just as easy to use
because it's also totally modular. So I can tuck it away in a loadable
library where its size and internal workings become irrelevant. All I need
then is an osax-style manual/dictionary to remind me how to use it, and a
'load script' or two.
And that's what AWPS is too: a loadable library [3] intended to be
easy-to-use and available to anyone who wishes to use it.
HTH. :)
has
--
[1] AWPS does use Standard Additions is used in a few places, but I'd still
describe it as vanilla since SA is part of the standard install.
[2] Disclaimer: I did initially use the Satimage osax in a couple of
parsing routines, but for some unfathomable reason AWPS developed stability
problems. [<sigh>I love regexes, but sooner or later every regex osax I've
used goes and breaks my heart<sob>.] In the end, I pulled those two lines
out and wrote a 100-line module to perform the same task. The replacement
code is slower, but since I'd already learned how to do good, economic
design this area was never part of the speed-critical rendering routines
anyway so isn't a problem.
[3] (Well, it will be once I rework it from its current script server
approach - a minor task.)
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.