bricks-devel Mailing List for bricks

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

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

bricks-devel Mailing List for bricks

bricks-devel — discussions on further development of Bricks Site Builder