4 Jun
2014
4 Jun
'14
10:48 a.m.
On Wed, Jun 4, 2014 at 10:12 AM, vincent(a)massol.net <vincent(a)massol.net>
wrote:
Hi Denis,
The goal of the UIX concept as I imagined it was for extensions to be able
to plug into the current skin to add dynamically new visual elements.
To achieve this, the main idea was that UIX should provide data as much as
possible (vs UI code) and that it’s up to the skin (vm files in general) to
decide how to display this data, based on its style, where it wants to
display it, etc.
You can provides macros for that purpose.
If you do it the other way (i.e. it’s the UIX that
does that UI) then you
have a big issue: a given UIX will only work well in one skin and will not
be perfectly well adapted to all skins.
But this is far more flexible and useful.
Said differently each UIX would need to know all
possible skins to make
sure it works in all of them, which is impossible to do since new skin can
appear.
This is also why I had ask for having more syntax for UI elements during
the last seminar.
Anyway, UIX will need to be careful to adapt themselves to the latest
skins, especially when their interface is complex.
Right now our UIX technology supports both strategies
and it’s a question
of best practices to decide how to use them.
The way it do so is weird.
What I would do, based on what we have, is to:
1) make UIX simple hook point where XWiki content could be injected.
2) provides macro that create a working and adapted UI for any know skin.
So, regarding the AppBar panel, you would have a macro {{AppBarIcon
label="App name" reference="App.WebHome" icon="icon:myicon"
current="$myAppActive" /}}
The last argument here is computed in a wrapping velocity macro that
determine if the App is the current one, and this could be app dependent
anf very flexible.
WDYT ?
Thanks
-Vincent
On 4 Jun 2014 at 09:51:20, Denis Gervalle (dgl(a)softec.lu(mailto:
dgl(a)softec.lu)) wrote:
--
Denis Gervalle
SOFTEC sa - CEO
Firstly, I couldn't understand why you bother
about knowing the currently
active application. The AppBar panel use an UIX, so the application
itself
has to produce the appropriate XDOM accordingly
to it's own state. Then I
discover that the UIX was not an UIX in fact, and all this thread about
application descriptor became clearer.
What is this UIX that looks like a macro call ? Why those parameters ?
Doesn't an UIX a hook to inject some UI in some place ? This is how I
have
always see it ? I should have missed a lot of
mail to not know that, or
it
has been implemented silently, but I miss it for
sure. I do not
understand
why there is anything so special about UIX that
require parameters. Why
do
we have added those parameters ? Couldn't we
simply use a macro in the
UIX
content ?
For keeping the AppBar flexible, the application should be able to manage
its display there fully. Imagine you write a calendar application, you
may
want to display the current date as an icon, and
the alerts next to your
icon, you may even want to have a popup showing the detail during a mouse
over. With a "normal" UIX, you should be able to do that. And if you just
want a very simple display, a default macro would be appropriate to
generate it based on the current parameters, isn't it ?
IMO, we should revert this feature ASAP. I am not against an application
descriptor, but not for managing an AppBar.
WDYT ?
On Mon, Jun 2, 2014 at 10:11 AM, Guillaume "Louis-Marie" Delhumeau <
gdelhumeau(a)xwiki.com> wrote:
> Good remark, indeed.
>
> So maybe the app descriptor should list the sheets that are used by the
> application?
>
>
> 2014-05-29 10:25 GMT+02:00 Marius Dumitru Florea <
> mariusdumitru.florea(a)xwiki.com>gt;:
>
> > On Wed, May 28, 2014 at 3:16 PM, Guillaume "Louis-Marie" Delhumeau
> > wrote:
> > > I'm pushing this thread up since we probably need an application
> > descriptor
> > > to know what is the current application (probably based on the
current
> > > space, but maybe not).
> > >
> > > It's important because now we have an AppBar...
> > > http://jira.xwiki.org/browse/XWIKI-10254
> > >
> > > What I personally need:
> > > - name of the application (already present as an UIX)
> > > - icon of the application (already present as an UIX)
> >
> > > - list of pages of the application or a list of spaces
> >
> > The application descriptor won't list the pages that the user creates
> > nor the spaces where the user creates those pages. You can have for
> > instance multiple blogs on the same wiki and you can have panels in
> > various spaces, not just inside the Panels space. The EM won't give
> > you this list either. What you'll get is the list of pages that hold
> > the application code/UI, most of them being hidden anyway (see also
> > the discussion about the application code space). What's more
> > important is to know the "type" of the current document the user is
> > looking at and to determine the application that provides that
"type".
> > The type is defined by an XClass, but
since a document can have
> > multiple objects you need to know which one is "the most important".
> > The natural answer is "the object that triggers the sheet used to
> > display the document". So I would determine the current application
> > based on the sheet that has been applied to the current document. If
> > you create a plain wiki page in the Blog space it doesn't mean the
> > current application is Blog. Same, if you create a blog post in a
> > different space that happens to be associated with some application
it
> > doesn't mean that application is
the current one, IMO.
> >
> > Hope this helps,
> > Marius
> >
> > >
> > > Do you have other things to add?
> > >
> > > Thanks,
> > > Guillaume
> > >
> > >
> > >
> > > 2014-04-15 16:23 GMT+02:00 Thomas Mortagne > > >:
> > >
> > >> On Tue, Apr 15, 2014 at 4:19 PM, Thomas Mortagne
> > >> wrote:
> > >> > On Tue, Apr 15, 2014 at 4:01 PM, Ecaterina Moraru (Valica)
> > >> > wrote:
> > >> >> Hi,
> > >> >>
> > >> >> There have been some recently discussions about Application
> > Descriptors
> > >> and
> > >> >> their utility when generating content for XWiki features,
like
> taking
> > >> the
> > >> >> icon field from the descriptor in order to generate the
application
> > >> panel
> > >> >> for the AppBar, etc.
> > >> >>
> > >> >> I've gathered some use cases / needs on this page:
> > >> >>
> >
http://design.xwiki.org/xwiki/bin/view/Proposal/ApplicationDescriptor
> > >> >>
> > >> >> It would be nice to brainstorm a bit if we consider the
> 'Application
> > >> >> Descriptor' concept to be needed in our future,
especially
since
> the
> > >> >> Flamingo Skin is focused heavily on the Applications
concept.
> > >> >>
> > >> >> I would be curious why this concept has been deprecated
> (Application
> > >> >> Manager):
> > >> >
> > >> > It hasn't been deprecated, it just never been in XE.
> > >>
> > >> Except for a short period of time where the old wikimanager was
moved
> > >> to XE until it was replaced
with the new wiki module.
> > >>
> > >> >
> > >> >> * maybe the fields the descriptor contained are deprecated by
the
> > >> Extension
> > >> >> Manager;
> > >> >
> > >> > There is no such thing as application descriptor in Extension
> Manager.
> > >> >
> > >> >> * maybe a bad usage;
> > >> >> * etc.
> > >> >>
> > >> >> And also very important is what fields you consider should
be
> needed
> > in
> > >> the
> > >> >> Application Descriptor and ways to make it easily
extensible.
> > >> >>
> > >> >> Having an Application Descriptor would facilitate having an
index
> > >> >> containing all
applications, called Application Index, in
order to
> > help
> > >> the
> > >> >> user navigate and manage the installed applications outside
the
> > >> Extension
> > >> >> Manager (which is found in Administration).
> > >> >
> > >> > I really don't see the point in having two indexes of
extensions.
> This
> > >> > is really not the main benefit we would get from an application
> > >> > descriptor.
> > >> >
> > >> >>
> > >> >> Thanks,
> > >> >> Caty & Louis-Marie
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs