Gunther Birznieks <gu...@ex...> wrote:
>I disagree in general with this. Having coded a lot of WML and HTML myself
>for a local mobile company, I can say pretty strongly that I do not believe
>in a 1-1 mapping between elements in WML and HTML except in a very loose
sense.
>
>You really have to code the whole template very separately for WML vs HTML
>and the choice you make (eg textfield vs textarea) is very different on WML
>vs HTML.
>
>So you would not want some generic Widget::TextField that rents a WML
>version for WML and HTML for HTML. It's quite possible that on web you may
>want to allow the user to type in a lot of info in textarea but on wap, you
>just restrict it a bit more.
Then perhaps the widgets are being too closely tied to the end result. The
Widget::TextField should know which way is best for the environment in which
it is being rendered. Why force the coder to figure out the best way to put
up a text input field? That complicates the higher-level coding and we have
lost the abstractions we are trying to put in place -- the developer has
gained nothing from using the Widget set except having to learn yet another
way to do things.
The Widget::Thingy class will know which of it's classes to use for rendering.
For HTML, it might use Widget::Thingy::HTML while in WAP it uses
Widget::Thingy::WAP. The Widget::Thingy class itself contains the logic used
to tie itself together, not actually render itself. If it has to worry about
which way to render a constituant widget, then it's not using a sufficiently
abstract widget.
Hopefully widgets will be more abstract than just Perl wrappers around the
HTML set of input objects.
--
James Smith <JG...@TA...>, 979-862-3725
Texas A&M CIS Operating Systems Group, Unix
|
