Hello

Trying to learn more about Turbogears, I read a lot of threads about
lot of things in this group.

Lot of post were about the problem of the poor integration of the
widget in the Turbogear's Model-View-Controller design.
Widgets cannot be designed/customised by editing the kid template,
because they are defined in the code! And then the web designer has no
control on it !

I thing the solution is not in TG but in the Web Authoring Tool (WAT)
used by the designer !
Anyway TG must help by adding some new features.

For the scenario I propose later, the widget definitions (in fact the
way it's instantiated, I mean the parameters) must be formalized in
it's own format and all the params stored in a separate file.
It's not difficult to format this

class CommentFields(widgets.WidgetsList):
    name = widgets.TextField(validator=validators.NotEmpty())
    email =
widgets.TextField(validator=validators.Email(not_empty=True),
                              attrs={'size':30})
    comment = widgets.TextArea(validator=validators.NotEmpty())
    notify = widgets.CheckBox(label="Notify me")

comment_form = widgets.TableForm(fields=CommentFields(),
                                 action="save")

in a XML or another more friendly format.
Of course the Widget definition can include python code, but kid
template also contains python code!  It's not impossible, just use a
"py:" notation like py:validators.NotEmpty() for example.
Suppose I get this definition in a file called "comment.wdgt" in the
new "widgets" subfolder near the "templates" subfolder

Now we can add the widget to our controller by a new @widget decorator.

    @expose(template=".templates.add")
    @widget("form", ".widgets.comment")
    def add(self, tg_errors=None):
        if tg_errors:
            flash("There was a problem with the form!")
        return dict()

The new decorator will instantiate the widget and then add it to the
function return value. This will populate the currently empty
dictionary to finally return { 'form' : the_instantiated_form }to the
expose decorator.

Now how to include this in the web design process?

Read this imaginary scenario.

Suppose you just finished your TG application (that include a lot of
widgets and kid templates), you start your application in "designer"
mode (something TG don't support yet,  this will start your application
for real and a kind of TG toolbox on another port that give access to
the kid templates and widgets definition by ftp or webdav). Then you
give your application URL, a login and a password to your web designer.

Your web designer start its WAT (Web Authoring Tool, not existing yet),
fill in the URL, login and password and get connected like with FF
(Firefox ) to your application. He can surf in your application and
when he want to change something, he just Ctrl-Right-Click on the
object, WAT identify the source of the object, inside a kid template or
a widget definition and propose the designer to modify it with an
appropriate interface.
Of course in this "designer" mode, TG must include some "mark" in the
HTML generated code to let WAT find the source of each HTML tag, source
that WAT will retrieve and update using the newly available webdav
access.

Of course this is unrealistic for tomorrow and this is not the job of
the TG team to write this WAT !

But the main idea of this post is that TG cannot solve alone the widget
dilemma.
I thing this is must be done by a not yet existing WAT !

Anyway I posted 2 interesting new ideas (new for me, maybe others get
them before) for TG:

First the idea of a new way to give the options and instantiate the
widgets. Maybe a kind of "tg-admin widget create" to create the widget
option files
And second add a "designer mode" to export the template and other
static file to any WAT by using Webdav or ftp.

And if these 2 things are done, it will not be too difficult for a web
designer using an existing WAT to find himself what source to edit to
get what he want! If everything is ready for a not yet existing
application to do the job, a human can dot it himself.

I finally a small Hint : widget must be used to simplify live, not to
do crazy thing. For crazy thing just use python and kid template, and
work together with your designer if your model require that your
designe must be done in your controller.

Hope this help

Alain


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"TurboGears" 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/turbogears
-~----------~----~----~----~------~----~------~--~---

Reply via email to