I have nothing against helpers as I use them a lot when involved with
a project to accomplish alone.
Working in team they are almost useless: the html code is usually the
source for your logic not a "product" to pass designers. You get html
static pages with style and putting in some logic is your business.
Seldom, at least in my everyday work you get the reverse.
>>designers can also use CODE, BEAUTIFY, .xml(), etc):
maybe in my dreams :-) They give you html and want back html to check.
Another issue is readability, the common "web2py mode" that I call
"everything in controllers" leads easily to monsters like this:
f2=FORM(FIELDSET(TAG.legend('COSTI JOB1',_id='daticosti'),\
TABLE(TR(TH('Lavoro/Materiale'),TH('UM'),TH('QT1/QT2/QT3'),TH
('Costo Un.'),TH('Totale')),\
TR(TD('Carta'),TD('Kg'),TD(SPAN(_id='carta_qt')),TD(SPAN
(_id='carta_cun')),\
TD(SPAN(_id='carta_tot'))),\
TR(TD('Lastre'),TD('Nr'),TD(SPAN(_id='lastre_qt')),TD(SPAN
(_id='lastre_cun')),\
TD(SPAN(_id='lastre_tot'))),\
TR(TD('Tiratura'),TD('min'),TD(SPAN(_id='tiratura_qt')),TD(SPAN
(_id='tiratura_cun')),\
TD(SPAN(_id='tiratura_tot'))),\
TR(TD('Avviamenti'),TD('min'),TD(SPAN(_id='avviam_qt')),TD(SPAN
(_id='avviam_cun')),\
TD(SPAN(_id='avviam_tot'))),\
TR(TD('Inchiostri'),TD('perc'),TD(SPAN(_id='ink_qt')),TD(SPAN
(_id='ink_cun')),\
TD(SPAN(_id='ink_tot'))),\
*[TR(rows_lavor[i]['descrizione'],db2(rows_lavor[i]
['idutilizzo_um']==db2.um.id).select(db2.um.nome)[0].nome,\
TD(INPUT(_id='lav_qt'+str(rows_lavor[i]
['id']),_class='lavj1',_value='0',_name=str(rows_lavor[i]['id'])),\
INPUT(_id='lav_qt2'+str(rows_lavor[i]
['id']),_class='lavj1',_value='0',_name=str(rows_lavor[i]['id'])),\
INPUT(_id='lav_qt3'+str(rows_lavor[i]
['id']),_class='lavj1',_value='0',_name=str(rows_lavor[i]['id']))),\
' eur '+('%.2f')%(rows_lavor[i]['costo']),\
....more
But I would not like to diverge from the central point: is there a
"style" we can agree to be regarded as a good web2py manner to code
forms? A part from our helpers debate, there are people who simply do
not want to use them (Tim Farrell is one of them I think I remember):
can we simply give a clear direction to people like that? Farrell had
to make his method up.
Also not any form can be auto submitted (and forms.accepts is not
available): what about forms submitted with ajax get/post ( a style
increasingly popular) ? In this case it is useless even to keep the
form object in controller.
carlo
On 18 Feb, 16:48, AchipA <[email protected]> wrote:
> A helper object can be used almost identically to a list. Helpers
> being able to 'render' themselves and including additional data (to
> ensure compliance, etc) is just a bonus for rapid prototyping. If you
> *depend* on rendering (and you need to hand that over to a design
> person), then you are likely abusing them (just like including html in
> your controller response is MVC abuse), but otherwise, there is
> minimal difference.
>
> I would seriously like to hear Massimo why he introduced HTML helpers.
> I personally find them very useful, but I'm not certain we're all
> talking about the same thing here with regard to MVC.
>
> example controller:
>
> return dict(listdata = (('col1', 'col2', 'col3'),('1','2','3'),
> ('4','5','6')), helperdata = TABLE(TR('col1', 'col2', 'col3'), TR
> ('1','2','3'), TR('4','5','6')))
>
> example view (I know this can be written in a more compact manner, but
> let's keep things simple for designers):
>
> Oldschool:
> <TABLE>
> {{for row in listdata:}}
> <TR>
> {{for cell in row:}}
> <TD>{{=cell}}</TD>
> {{pass}}
> </TR>
> {{pass}}
> </TABLE>
>
> Rapid prototype (designers can also use CODE, BEAUTIFY, .xml(), etc):
> {{=helperdata}}
>
> Oldschool, but based on helper data:
> <TABLE>
> {{for row in helperdata.components:}}
> <TR>
> {{for cell in row:}}
> {{for data in cell:}}
> <TD>{{=data}}</TD>
> {{pass}}
> {{pass}}
> </TR>
> {{pass}}
> </TABLE>
>
> See ? It's the almost the same thing, helpers are just custom objects,
> you can do with them as you please.
>
> On Feb 18, 2:52 pm, carlo <[email protected]> wrote:
>
> > everything is debatable: only side thing I can argue is that helpers
> > are objects related to markup and I do not like them mingled with
> > logic. But that's philosophy I agree.
>
> > The main real point is that if you want to share your work with html
> > designers, you can not use helpers at all. Your designer gives you
> > markup and style: the more you have this separated from your logic the
> > better integraton ease.
>
> > carlo
>
> > On 18 Feb, 01:58, AchipA <[email protected]> wrote:
>
> > > One of the returning moments on this list is that when I say helpers
> > > in controllers, people hear 'html in code'. The two have (almost)
> > > nothing in common, even though it's possible to overuse/abuse helpers
> > > (just as you can put html in strings in controllers - obviously bad).
> > > Then again, maybe it's just me having an awkward POV on helpers :)
>
> > > My main question is - why do people consider transferring only stock
> > > variable/list/dictionary python objects to the views 'cleaner' than
> > > transferring any other python object to it (helper objects, or even
> > > your own) ? Helpers create *objects* which are just data wrappers.
> > > They are *NOT* strings and have nothing in common with HTML until the
> > > point they get rendered.
>
> > > On Feb 18, 12:03 am, carlo <[email protected]> wrote:
>
> > > > On 17 Feb, 23:39, AchipA <[email protected]> wrote:
>
> > > > > web2py gives quite some latitude with regard to doing things... I
> > > > > understand there are major no-nos, but is there a best way ? We had
>
> > > > Sorry but I would be more narrow minded about this: from my point
> > > > there *should* be never a good reason to put html in controllers: it
> > > > makes code difficult to debug, to read and to share with designers.
> > > > Isn't this one of the reasons for php and java servlets failure in the
> > > > enterprise?
>
> > > > carlo
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"web2py Web Framework" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---
