[katello-devel] Thinking about NuTupane Architecture

[Ivan Necas]

----- Original Message -----
> On 03/01/13 04:00 PM, Jason Rist wrote:
> > There comes a time when you realize you didn't design something
> > very
> > well the first time and it needs to be refactored so that it's
> > better
> > from a UI/UX perspective, but also better from a development
> > perspective.  We've got designs already here
> > https://fedorahosted.org/katello/wiki/Foreman%20Integration
> > and
> > https://fedorahosted.org/katello/wiki/Organization
> > that approximate what we're going for on the design side, but don't
> > take
> > into consideration the architecture of how we're planning on
> > developing
> > them.
> >
> > This is a solicitation for advice and input on how we might best
> > design
> > this.  Things to keep in consideration:
> > 1.) We'll want to be able to make a single change that is visible
> > on
> > every page that utilizes NuTupane.
> > 2.) We'll want to be able to override individual settings for
> > special cases.
> > 3.) We'll want to integrate search functionality and fancyqueries
> > search
> > saving as we do now.
> > 4.) We'll want to consider batch actions for everything from the
> > beginning and be able to disable based on permissions or where not
> > applicable.
> > 5.) We'll want to disable individual components of the NuTupane
> > based on
> > permissions or where not applicable.
> >
> > Based on experience, it'd be ideal if much of this is done in the
> > controller and the view is sort of dumb so that we can avoid logic
> > and
> > business type rules in the view.
> >
> > Help?
> >
> > Thanks,
> > J
> 
> I think Jason together with everyone else working on alchemy/tupane
> layout did a good job - I never used/worked with views of this
> complexity in a web-application.
> 
> As long as the views do not deviate from the standard ones and do not
> require custom ui elements, the mixed (html+js) approach to
> developing
> views works quite well. However, it introduces some issues (in
> addition
> to the ones mentioned by Jason):
>   - oftentimes controllers require additional methods to
>   retrieve/update
> a particular part of the view
>   - creating custom UI elements is time consuming
>   - testing of interactions between individual ajax elements/calls is
>   hard
>   - somewhat related to the one directly above - custom page/tab
>   updates
> are hard (i.e. only specific UI elements need to be updated, the
> whole
> tab needs to be re-rendered, etc)
>   - page assembly is mostly defined by templates, which makes
> customization/testing hard
> 
> What if we used pure js controllers and views (think backbone, or
> other
> "real" MVC approach) working against API controllers? This approach
> would potentially address quite a few of the issues/concerns above,
> and
> improve testability too.

+1 for utilizing the API controllers for UI. Having a single entry-point for
the application logic for both UI, CLI and others soundls like a big win.

Of course, it's not trivial and would need some research, but as written below, it
doesn't have to be all-or-nothing rewrite since this two approaches can sit side by side.

> 
> I suspect that we'd be able to support both approaches (the one
> currently used and pure js one) simultaneously, which eliminates the
> need for "one big rewrite".
> 
> While I don't think we should plunge into this head-first, I do think
> the idea warrants a trial/spike. Thoughts/opnions?

+1

-- Ivan
> 
> -d
> 
> _______________________________________________
> katello-devel mailing list
> katello-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/katello-devel
>