Anthony, your last paragraph is quite interesting. I work for a large
corporation, which for good or bad, has back-end web programmers, but also
simple html designers. The concept of embedding HTML helpers A(), FORM() in
controllers, or modules is frowned upon and it was one of the main reasons
they almost dropped the platform altogether since the perception was that
the developers would end up making a "mess" and leave the designers with an
interface that is very hard to customize if you don't know python for
example.
I personally do not use html helpers *at all*, but I can see why for some
folks it can be a time saver.
Nowadays, I am designing more for mobile than for the desktop, and I am
moving web2py to a new paradigm, I am providing the UI entirely for example
via jQuery Mobile, or Kendo, and use web2py as an API, service oriented
application framework, I find the html helpers are even less needed in this
context, as web2py provides me with data abstractions and not view
components, and for the MVC/MTV zealots, that is actually a good side
effect, heck, even desktop web apps are now becoming "single page" (think
facebook, tweeter, etc).
I am comfortable where web2py is heading, it is becoming a large framework,
and every developer must evaluate what parts of the framework you want (or
need) to use.
I think one of web2py's main "problems" (as seen from many of their
detractors), is that it allows the newbie to very easily create
database-driven applications - sometime large ones - in which basic
software engineering principles are not applied correctly (or at all), this
include antipatterns such as the "god" class, asynchronous gotchas and the
like, I am not saying you cannot do them in other platforms, but it is
"easier" in web2py.
On Friday, February 6, 2015 at 8:50:41 AM UTC-8, Anthony wrote:
>
>
> ..snip..
>>
> Another example is in the search function on the simple wiki:
>>
>> def search():
>> """an ajax wiki search page"""
>> return dict(form=FORM(INPUT(_id='keyword',_name='keyword',
>> _onkeyup="ajax('callback', ['keyword'],
>> 'target');")),
>> target_div=DIV(_id='target'))
>>
>> Why create a form that not need any kind of postprocessing, even adding a
>> onkeyup attribute, in the controller, when all this code, following MVC
>> should go in the view?
>>
>
> I agree that could just as easily go in the view, but I don't see the harm
> in having it here. Because most forms do involve processing/validation,
> they are typically defined in controllers, so it makes sense to stick with
> that standard even when no processing is happening. It's odd to say that
> FORM(...).process() belongs in the controller but FORM(...) without the
> .process() must go in the view.
>
> Also, keep in mind that the overview chapter is just a relatively simple
> introductory tutorial. It is not meant to communicate how one ought to
> architect a large complex application. I'm not saying we couldn't consider
> changing some of the code examples, but I don't see it as a major
> indictment of MVC violation.
>
> Anthony
>
--
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
---
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
