[Seaside] Is your code for your Seaside web-app using concisemethods?

[Rick Flower]

Ramon Leon wrote:
>
> Ok, take everything I say with a grain of salt, no critiques is intended I'm
> simply offering my opinion.  
>   
I like some good constructive criticism.. I'm fairly new to ST and have 
only been using it for <1 year
and I like to learn techniques from those more knowledgeable than I am 
-- particularly here!
> So, lets start with this method.  First, I'd separate the controller code
> from the view code so that I could categorize and reuse those queries, and
> remove all temp vars from my rendering.  I don't like declaring variables in
> the render methods, it too easily leads to logic in rendering methods.  It
> also makes it hard to find things later.  I find it much easier to find a
> query by selecting the "query" method category and looking at method names,
> rather than digging through view code. So...
>
> userList
>     ^self session db 
>         readManyOf: MSADBUser 
>         where: [:each | each org id = org id]
>
> scripList
>     ^self session db
>         readManyOf: MSADBScrip 
>         where: [:each | each org id = org id].
>   
Ok .. Sounds reasonable.. I probably would have done that eventually anyway.
> Ok, with those removed, some methods renamed, most of the breaks removed
> from the rendering, and a more Smalltalkish code formatting where blocks
> don't begin/end on their own lines, we could shorten the render method to
> this.
>
> [ ... ]
>
> Now, one thing you'll notice I changed was your method names.  The style you
> chose is rather repetitive because you chose to pass the canvas first,
> rather than last and you end up repeating your arg name twice in the
> selector.  So this...
>
> self renderUserSelectList: html withUserList: userList
>
> Becomes...
>
> self renderUsers: self userList on: html
>
> So I don't have to say user list twice in the selector.  Personally, I
> always pass the canvas last with #on: because I'm thinking "Draw this stuff
> on that canvas".  
>
> I also try to avoid using technology names in my selectors, they add tend to
> be longer and less able to cope with change that simple domain language
> selectors.  For example, #renderFamilyAndOrgDivs:withOrg: becomes
> #renderOrg:on: and #renderUserSelectList:withUserList: becomes
> #renderUsers:on:.  
>
> Now if I later change the layout to not use divs, or to use a Set or
> Dictionary of users instead of a list, I don't need to rename my methods
> because they were written in the language of the domain rather than the
> language of the implementation technology.
>   
Excellent comments!  I guess I got so caught up in writing the code that 
I wasn't seeing the forest for
the trees on that one.. Your suggestions make a lot of sense and do a 
nice job of keeping things
more OO like and avoiding implementation details in places that don't 
need to know about that sort
of stuff.
> As for CSS, I extract "all" CSS to external files with the exception of
> #style:'display:none;', which I use a lot when doing ajaxy stuff where I
> render something hidden for later.  Removing all CSS will clean up the code
> a bunch, and give you a more flexible skinable application to boot.
>   
Sounds good.. Most of my CSS is external in separate files care of my 
old PHP days.  I think I like doing
that better than having Seaside hitting the server a bunch of times for 
those more complex pages with
lots of objects containing internal style methods that need to be 
fetched during the drawing process.
> As for Ajax, one thing I see in your code that I think could simplify
> things, would be to always extract the body of a liveCallback into its own
> rendering method.  This will save you from having to write the code twice
> (denominationListDropDown), once for the initial render, and then once again
> in the liveCallback each time the drop down list changes.  By factoring this
> duplicate code into a single render method, you can call it on the initial
> render with the seaside canvas and the list #('Select a Vendor First' ), and
> call it from the live callback with the ajax canvs and the list from (item
> denominations reject: [:each | each 
> denomination = 0]).
>   
OK.. Sounds reasonable as well..
> One final thing, I tend to use symbols for my #class: and #id: selectors
> rather than strings because I "think" it uses less memory and I feel it
> looks much better.  Seaside at one time, had an issue with too many strings
> building up.  See http://www.nabble.com/Seaside2.7a1-avi.10-t2319420.html,
> but that was fixed, but I never changed the habit
>   
Hmm.. I'm not sure I've ever really looked at ST symbols before.. I 
gather (upon doing a little homework
just now) that I just need to use something like #MyDivName or similar 
to get a symbol instead of a
string such as 'MyDivName' like I am doing currently?  I guess I didn't 
really realize that ST was likely to
be keeping multiple copies of those strings for all of the different 
methods that were using them.. Are there
any other pitfalls with using symbols?  I ran across a blog entry 
suggesting that new ST'ers frequently use
gratuitous use of symbols and have big performance hits (see link below 
-- particularly the last comment)
under certain conditions.. I'll have to admit that they indicate that 
you should use "asSymbol" to get
the symbol object instead of creating what would sound (to me anyway) 
like another symbol..
Am I barking up the wrong tree or just misunderstanding symbols?

http://www.cincomsmalltalk.com/userblogs/troy/blogView?showComments=true&entry=3313219321

Many thanks so far for the great info Ramon!