[Bricks-devel] Re: Got the idea... roughly;-)
Status: Beta
Brought to you by:
petermcd
Menu
▾
▴
[Bricks-devel] Re: Got the idea... roughly;-)
|
From: Peter M. <ilu...@ho...> - 2001-07-23 23:02:58
|
<html><div style='background-color:'><DIV>
<P>Hope the code wasn't too difficult to get through.<BR><BR>>From "P.Fleury" <FL...@US...></P></DIV>
<DIV></DIV>>To: pe...@pm...
<DIV></DIV>>Subject: Got the idea... roughly;-)
<DIV></DIV>>Date: Mon, 23 Jul 2001 11:13:25 +0900
<DIV></DIV>>
<DIV></DIV>>Hi again !
<DIV></DIV>>
<DIV></DIV>>This week-end (which was a 3 days week-end here in Japan) I went
<DIV></DIV>>through
<DIV></DIV>>the code of Bricks. I think I have a good idea of what is in there
<DIV></DIV>>now,
<DIV></DIV>>and I also finally got what you use redirect/mappings etc. for. All
<DIV></DIV>>this raised some fundamental questions, for which I could not
<DIV></DIV>>reverse
<DIV></DIV>>engineer your sequence of thoughts when designing this.
<DIV></DIV>>
<DIV></DIV>>1) You deal with encapsulating Mason components, using the
<DIV></DIV>>Apache->request directly, need some caching, etc. Why isn't the
<DIV></DIV>>Brick.pm
<DIV></DIV>>a Mason component in the first place ? Then, you would not have to
<DIV></DIV>>care
<DIV></DIV>>about caching, you could use Mason's request object (which can be a
<DIV></DIV>>hand
<DIV></DIV>>crafted if run from a script, which I do have :-).
<DIV></DIV>
<P> </P>
<P>One reason is that I would like to be able to write "pure perl" bricks. For example, column, which is by far the most commonly used brick, could be rewritten as just a perl class. My hope is that pages will render faster under pure perl rather than mason + perl. I'm not certain that this will happen, but Bricks did get significanltly faster when I moved the 'core' code, what's now in the .pms, from Mason to Perl.</P>
<P>The downside is that you can't use some of Mason's features. Virtual hosting would probably also be easier with pure Mason. Also, I prefer the $rbrick->method_name(...) call mechanism to $m->comp('brick_name:method_name',...) mechanism.</P>
<P> </P>
<DIV></DIV>>2) Extending/writing new Bricks seems to place a lot of the burden
<DIV></DIV>>to
<DIV></DIV>>the Bricks writer. Doing thing recursive is neat programming, but
<DIV></DIV>>then
<DIV></DIV>>each object has to deal with things like parsing the tree of bricks,
<DIV></DIV>>routing calls, walking, etc. I would see like 2 types of Bricks:
<DIV></DIV>>structure bricks ( column, assembly, table, etc.) for which this
<DIV></DIV>>complexity is needed, and simpler bricks (provided ones like Text,
<DIV></DIV>>Image, etc.) and a wrapper brick which needs the new Brick creator
<DIV></DIV>>write
<DIV></DIV>>only the absolutely necessary portion of the code. (This complexity
<DIV></DIV>>hiding would most probably trigger more Bricks being written. Then
<DIV></DIV>>people get used to it, can broaden their knowledge of the system,
<DIV></DIV>>and
<DIV></DIV>>write more comple ones :-)
<DIV></DIV>
<P>> </P>
<P>It should currently work just as you would like it to. There are two classes of bricks: containers such as column, table, and assembly, and there are leaf-nodes, such as text, photoalbum, etc.. The user should only have to implement a method such as route_sub or walk on bricks that are containers.</P>
<P>In fact, a user doesn't have to implement any method other than render for a brick to work.</P>
<P> </P>
<DIV></DIV>>3) Also the bricks have to render themselves in edit mode as well as
<DIV></DIV>>in
<DIV></DIV>>normal mode. Whereas I think this is ok for complex bricks (table)
<DIV></DIV>>which
<DIV></DIV>>also need some specific rendering for easier editing (e.g. the
<DIV></DIV>>split/join icons). I we want to add something like a frame around
<DIV></DIV>>each
<DIV></DIV>>brick in edit mode, and have a title bar with a few icons in there,
<DIV></DIV>>representing actions like "add element", "remove brick", "edit brick
<DIV></DIV>>properties", then we will have to modify each of them... This
<DIV></DIV>>coupling
<DIV></DIV>>is not good in the long run I think.
<DIV></DIV>
<P> </P>
<P>Actually, the 'tabs' that have the brick name, the brick number, and draw the box are drawn by column before it calls render() on the brick. You might be thinking of the render_edit method? This is used to render the brick properties. For example, with the text brick when you want to edit the text inside the brick, the html form is rendered with render_edit and a redirect.</P>
<P> </P>
<P> </P>
<DIV></DIV>>This all looks like huge work, I know :-) So that is why I would
<DIV></DIV>>like to
<DIV></DIV>>know if there are issues you have foreseen that I just do not see.
<DIV></DIV>>
<DIV></DIV>>However, there are a few things which I found very interesting in
<DIV></DIV>>the
<DIV></DIV>>way you tackle the problem:
<DIV></DIV>>- your way of defining arguments for bricks, and the way you route
<DIV></DIV>>them,
<DIV></DIV>>- bricks with a set of methods, which actually defines Bricks as
<DIV></DIV>>bricks
<DIV></DIV>>the way Java defines Beans, by adhering to API conventions only.
<DIV></DIV>>- the freeze/thaw mechanism, which I think could be reused for
<DIV></DIV>>store/save and backup/restore.
<DIV></DIV>>- the way one can handle tables within a browser, that's killer :-)
<DIV></DIV>
<P>> </P>
<P> </P>
<P>I haven't played with Java Beans, but yes, I think that freeze/thaw could be used for the backup/restore function. I just think it should be modified a little to facilitate off-line editing.</P>
<P> </P>
<P>You like the table stuff, eh? Are you familiar with cascading style sheets? It looks to me like people on the web are working to replace tables as a layout tool with cascading style sheets. It's something else that needs to be looked at.</P>
<DIV></DIV>>I will probably try to write down the global design of Bricks in
<DIV></DIV>>some
<DIV></DIV>>form. Writing this kind of documentation helps me understand things,
<DIV></DIV>>and
<DIV></DIV>>leaves a nice document around...
<DIV></DIV>
<P>> </P>
<P>Sounds good. </P>
<P> </P>
<P>-Peter</P></div><br clear=all><hr>Get your FREE download of MSN Explorer at <a href='http://go.msn.com/bql/hmtag_itl_EN.asp'>http://explorer.msn.com</a><br></html>
|