Re: [Tutor] More and more OT - Python/Java
On Wednesday 12 January 2005 00:34, Max Noel wrote: As a bonus, I've decided to have a look at XSL, which allows me to format a XML file for display in a web browser. It entirely changed my perception of web programming. I intend to program an on-line browser-based game with some friends of mine later in the year (in Python of course -- I converted them), and now that I've seen what XML and XSL can do, we're so going to use them for data output: the data is in dynamically-generated XML, which links to a (static) XSL stylesheet to tell the browser how to render that data. Hi Max, While I agree that the XML + XSL - HTML architecture *sounds* very nice, in real life it's not so sweet. I've worked on some projects that used this approach and IMHO, the biggest problem is the debugging of XSL output -- XSL scripts are a horror to read, and the complex matching rules often make it very hard to discover which template caused which error. In this case I'd suggest a templating language, such as TAL (part of Zope, http://www.zope.org) or a different language. At my work (Java) we now use JSP, a Java templating language; debugging time has significantly decreased by using this instead of XSL. Doing things that way has many advantages: 1) Data is separate from formatting. That's always a Good Thing(TM). If I someday decide that I don't like the way the site looks, I theoretically only need to recreate a stylesheet, without touching anything else. (boom! Instant skins!) You're completely right, but as I pointed out, XSLT is not the only option. 2) Most of the HTML rendering is going to be done by the user's browser. This, and the way XSL stylesheets are constructed will prevent many bad HTML issues. HTML rendering is usually not an issue for web-based programs. And if it is, a bit of front-end caching usually can save a lot more time. After all, whether you have to render HTML or XML, you do have to render something. As for the bad HTML issues, the same issues (unclosed tags, wrong attributes) do exist when rendering XML. 3) For the same reason, it will save bandwidth. The XML data will probably take less space than the fully-formatted stuff I'd have to spit out with regular HTML, and the XSL stylesheet can probably be cached by the user's browser. As Alan pointed out, this might very well not be true :-) 4) In the same line of reasoning, it'll also save CPU time: XML data, being smaller, is generated faster than the equivalent HTML. Granted, the stylesheet is another server request, but it's static, so it puts virtually no load on a server. My answer to this is the same as nr 2. Yigal ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] More and more OT - Python/Java
On Wednesday 12 January 2005 09:40, Alan Gauld wrote: I ask that because I'm writting a little program that will make queries over a 1500 entries database, with very simple queries. I need an answer in 1 or 2 seconds. I'm using SQLite now, but i wanted something that depends as little as possible of external dependencies (as a database). 1500 entries shouldn't be a problem for queries either using DOM (in memory) or XPath or even XQuery. If your app grows to 15 it might stat to be a problem, and if you get over a million entries I'd definitely start thinking about regular RDBMS. The other feature is that for ~1500 entries the size of the files will be about the same but anything bigger than that and the XML version will quickly start to fill your disks... I actually have some realy life experience with using XML files instead of a database, and it's a bit of a mixed blessing. A big advantage of XML over a relational database is the built-in support for hierarchical structuring. When you're mainly reasoning about trees (in this particular case, parse trees) the relational solution is a bit... messy. For example, to find all assignment statements at the top-level of a function, XPath allows you to say something like: //function-definition/[EMAIL PROTECTED]assign] the equivalent is SQL is not so nice. On the other hand, the amount of XML our project produced was *huge*, and much of the processing time of the project went into parsing XML. Furthermore, while XPath allows for very cute queries, no XPath implementation is as optimized as SQL. All in all, I'd never advise XML as a database. Yigal ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] class instance with identity crisis
On Wednesday 12 January 2005 12:10, Kent Johnson wrote: A couple of ideas: You could have dry() return the new weapon: def dry(self): return Prune() then the client code would be weapon = weapon.dry() You could have the weapon encapsulate another object and delegate to it. As an alternative solution, you could use the Proxy pattern; this approach has the advantage that there is no dynamic reassignment of the __class__ attribute. The following program shows what I mean: class Apple: def whoami(self): print I am an apple! def __str__(self): return Apple class Egg: def whoami(self): print I am an egg! def __str__(self): return Egg class Proxy: def __init__(self): self.delegate = Apple() self.is_apple = True def __getattr__(self, attr): return getattr(self.delegate, attr) def change(self): if self.is_apple: self.delegate = Egg() else: self.delegate = Apple() self.is_apple = not self.is_apple if __name__ == __main__: thing = Proxy() thing.whoami() print thing thing.change() thing.whoami() print thing thing.change() thing.whoami() print thing This will give the following output: I am an apple! Apple I am an egg! Egg I am an apple! Apple The magic here lies in the __getattr__ (note the double underscores) method; whenever the Proxy is asked for an attribute (such as a method), it delegates this question to the self.delegate. Alternatively, if the __getattr__ is a bit too much magic, you could also duplicate the attributes that you actually want to expost: class Proxy: def __init__(self): # as above def whoami(self): self.delegate.whoami() def __str__(self): return str(self.delegate) def change(self): # as above As others have stated, you should use this pattern with care. On the other hand, I do believe that there are instances when this can be useful, as long as the delegates have more or less the same interface (the same attributes). Yigal ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
