rave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Franklin <m.ben.frank...@gmail.com>
Subject Re: API frontend split
Date Sat, 31 Jan 2015 13:33:47 GMT
On Sat Jan 31 2015 at 7:48:05 AM Contacto <contacto@aguilardelgado.com>
wrote:

>
> >> Hi all,
> >>
> >>   From RAVE-1293 issue. It would be nice to separate API and frontend
> code.
> >>
> >> I have a fork of the project that works on wicket+bootstrap+jquery. I
> >> have themes and dasboard like rendering working. But's a pain to make
> >> everything looks as the old frontend (at least in class names and ids)
> >> to make everything working.
> >>
> >> I don't want to share the code because it will do more harm to current
> >> development than good. Since you still suffering a lot to put in fit the
> >> angular code. Maybe when everything is clear we can take a look on how
> >> to merge. And you don't want a new uber patch laying around that don't
> >> really works.
> >>
> >> So far I have rendering fixed, move widget fixed and I'm on the
> >> properties panel of each widget partially working. It integrates well
> >> with spring security and other technologies inside rave. I will setup a
> >> demo page as soon as I fix preferences panel issues.
> >>
> >> It will help if I can use my own code rendered from wicket to maximize,
> >> change properties ETC. But for this API must be separated from ui code.
> >>
> >> Will someone work on this?
> >>
> > I think separating the API from the front-end should allow you to tie in
> > your custom front end much more easily.  I am signing up to help finish
> the
> > removal of all JSP and Spring MVC front-end code.
> Great. Once we have latest code on master/develop branch we can do
> blueprints for this split. But for me it's easy to see what we really
> need first.
>
>   * A clean API to:
>       o Get a widget from its id.
>       o Make the widget render.
>       o Get properties of a widget.
>       o etc.
>

A lot of these APIs exist today, we just need to round them out and make
them the only entry point on the server side.


>   * Any rendering dependant stuff, I mean setting up the class of an
>     item,adding objects to html, connecting callbacks, etc. via
>     javascript should be done in a frontend specific library/module.
>
> Maybe part of this work is already done in the angular branch. But I
> don't know.
>
>
>
> >
> >
> >> Best regards.
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message