esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vassil Dichev <vdic...@apache.org>
Subject Re: Moving UI code out of server code
Date Tue, 02 Jun 2009 06:55:30 GMT
Hey Mrinal,

I hope I can answer some of the questions, which David can confirm and
expand on later.

> 1. Login form*  *-  the html for the login forn sits in the User Model ...
> it would be great if this could be moved out.

Yes, that seems high priority. Another model class with html inside is Message.

> 2. Edit user form -  I know that the redirection to this happens in
> UserSnip.scala .. but I'm not really sure how thr form actually gets
> generated ... I think it some how gets generated from the model .. I suspect
> somewhere in User.scala

Actually it's not even in ESME code- it's the already mentioned in the
mailing list MetaMegaProtoUser. A bit more effort is involved in
separating the code from this MetaMegaProtoUser, because we'll need to
extract the functionality in our own ESME classes.

> 3. Menus - configuring what menu appears on which page and how to change
> their labels took me a lot of time to figure.... and some I just could not
> figure out .. so I ended up changing labels after load in javascript.

The menus are defined using net.liftweb.sitemap.Menu. You're probably
having problems locating those in the View classes, but they're
gradually getting refactored so the menu setup happens at
bootstrap.liftweb.Boot.

The menu items can be used using the <lift:Menu.item name="..."/>
elements. You should be able to change the name if you provide text
for the node, like this (example from Starting with Lift,
http://liftweb.net/docs/getting_started/mod_master.html):

<lift:menu.item name="Login">Log In</lift:menu.item>

> On a more broader note ...
> I think that the *controller of the UI* in a complex app like ESME should
> actually sit in the UI and not in on the server ... the sever should act
> more like a model to/from which you can send/recieve data, authentication
> etc.  ....  this gives the UI developer a lot of control on how he wants the
> UI to behave ... UI behaviour like lets say ... transitioning from one view
> to another with a nice effect and no page redirects is much easer to do like
> that.

Not sure I understand what you mean by "controller of the UI", you
could put menu items to different ESME views in any html, right?

Having the menu item names defined in Scala is a good thing actually,
so you have a uniform name you can refer to from the html. If you had
to know the URL you point to, this limits the capability for
refactoring. In Lift the name and the label that's displayed are not
coupled (though there is a default, you don't have to use it).

On a more optimistic note, the ActionView, Track and Auth views are
refactored to html. Unfortunately, the bigger and more important views
still remain (related to user and login).

I hope that answers some of your questions (and hopefully I got
everything right).

Cheers,
Vassil

Mime
View raw message