3 Nov
2011
3 Nov
'11
11:56 a.m.
Hi devs,
I'm implementing the LinkChecker UI and I want to be able to add a Tab in AllDocs.
Right now I've coded it with a hardcoded #if but I really hate this.
So here's my proposal:
* Create the following modules:
xwiki-platform-uiextension/
|_ xwiki-platform-uiextension-ui/
|_ xwiki-platform-uiextension-api/
where:
* xwiki-platform-uiextension-ui/: contains XWiki.UIExtensionClass page
* xwiki-platform-uiextension-api/: contains a ScriptService to get UIExtension data +
contains an EventListener that refreshes the UI Extension Cache when an UIExtensionClass
object is modified (this is for performance reasons)
To start with I'm proposing to have the following fields for UIExtensionClass:
* type: String, represents the type of the extension (for example for the AllDocs needs,
I'll use a "IndexTab" type (or "AllDocsTab" type)
* id: String, the technical name of the extension, which can be used for example as suffix
for HTML class or ids.
* name: String, the name of the extension, which can be used for displaying. For example
for the AllDocs needs, it would be used as the name of the Tab
* content: Textarea: the content of the extension. For example for the AllDocs needs, it
would be used as the content to display when clicking on a tab
I'd like to implement this ASAP and thus stop hardcoding UI Extensions from now on.
Here's my +1
Thanks
-Vincent
PS: If you find a better than "uiextension" I'm all ears. A name without
"extension" would be great to not confuse it with our Extensions (and with
xwiki-platform-extension).
3 Nov
3 Nov
12:06 p.m.
New subject: [xwiki-devs] [VOTE] Creation of xwiki-platform-uiextension module
On Thu, Nov 3, 2011 at 11:56 AM, Vincent Massol <vincent(a)massol.net> wrote:
Hi devs,
I'm implementing the LinkChecker UI and I want to be able to add a Tab in AllDocs.
Right now I've coded it with a hardcoded #if but I really hate this.
So here's my proposal:
* Create the following modules:
xwiki-platform-uiextension/
|_ xwiki-platform-uiextension-ui/
|_ xwiki-platform-uiextension-api/
where:
* xwiki-platform-uiextension-ui/: contains XWiki.UIExtensionClass page
* xwiki-platform-uiextension-api/: contains a ScriptService to get UIExtension data +
contains an EventListener that refreshes the UI Extension Cache when an UIExtensionClass
object is modified (this is for performance reasons)
To start with I'm proposing to have the following fields for UIExtensionClass:
* type: String, represents the type of the extension (for example for the AllDocs needs,
I'll use a "IndexTab" type (or "AllDocsTab" type)
Not sure about the type name, maybe more something like
"enterprise.indexTab" to follow configuration and translation keys
standard.
* id: String, the technical name of the extension,
which can be used for example as suffix for HTML class or ids.
* name: String, the name of the extension, which can be used for displaying. For example
for the AllDocs needs, it would be used as the name of the Tab
* content: Textarea: the content of the extension. For example for the AllDocs needs, it
would be used as the content to display when clicking on a tab
I'd like to implement this ASAP and thus stop hardcoding UI Extensions from now on.
Here's my +1
+1
I'm ok with "uiextension".
Thanks
-Vincent
PS: If you find a better than "uiextension" I'm all ears. A name without
"extension" would be great to not confuse it with our Extensions (and with
xwiki-platform-extension).
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
12:40 p.m.
New subject: [xwiki-devs] [VOTE] Creation of xwiki-platform-uiextension module
On Nov 3, 2011, at 12:06 PM, Thomas Mortagne wrote:
On Thu, Nov 3, 2011 at 11:56 AM, Vincent Massol
<vincent(a)massol.net> wrote:
Agreed.
BTW AFAIR the naming convention for translation keys is:
<top level project name>.<module name>.<key name>
Which would mean here (once AllDocs has been moved to xwiki-platform-navigation -
let's assume that's how we want to call it):
platform.navigation.indexTab
Not sure what to put for XE now since AllDocs is in XE, maybe enterprise.xe.indexTab?
Hi devs,
I'm implementing the LinkChecker UI and I want to be able to add a Tab in AllDocs.
Right now I've coded it with a hardcoded #if but I really hate this.
So here's my proposal:
* Create the following modules:
xwiki-platform-uiextension/
|_ xwiki-platform-uiextension-ui/
|_ xwiki-platform-uiextension-api/
where:
* xwiki-platform-uiextension-ui/: contains XWiki.UIExtensionClass page
* xwiki-platform-uiextension-api/: contains a ScriptService to get UIExtension data +
contains an EventListener that refreshes the UI Extension Cache when an UIExtensionClass
object is modified (this is for performance reasons)
To start with I'm proposing to have the following fields for UIExtensionClass:
* type: String, represents the type of the extension (for example for the AllDocs needs,
I'll use a "IndexTab" type (or "AllDocsTab" type)
Not sure about the type name, maybe more something like
"enterprise.indexTab" to follow configuration and translation keys
standard. > * id: String, the technical name of the extension,
which can be used for example as suffix for HTML class or ids.
> * name: String, the name of the extension, which can be used for displaying. For
example for the AllDocs needs, it would be used as the name of the Tab
BTW one more detail. We need to allow wiki syntax in the "name" field value
since we'll want to support translations.
The other option, maybe better, is to make it a translation key, or even better, do as we
have suggested for internationalizing the Rendering module, i.e. let the user specify
either a human-readable string or a translation id. For example: "My Name",
"${platform.linkchecker.linkTab}" (syntax to be defined).
Thanks
-Vincent
* content:
Textarea: the content of the extension. For example for the AllDocs needs, it would be
used as the content to display when clicking on a tab
I'd like to implement this ASAP and thus stop hardcoding UI Extensions from now on.
Here's my +1
+1
I'm ok with "uiextension".
Thanks
-Vincent
PS: If you find a better than "uiextension" I'm all ears. A name without
"extension" would be great to not confuse it with our Extensions (and with
xwiki-platform-extension).
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 
1:13 p.m.
New subject: [xwiki-devs] [VOTE] Creation of xwiki-platform-uiextension module
Hi Vincent,
On Thu, Nov 3, 2011 at 12:56 PM, Vincent Massol <vincent(a)massol.net> wrote:
Hi devs,
I'm implementing the LinkChecker UI and I want to be able to add a Tab in
AllDocs. Right now I've coded it with a hardcoded #if but I really hate
this.
So here's my proposal:
* Create the following modules:
xwiki-platform-uiextension/
|_ xwiki-platform-uiextension-ui/
|_ xwiki-platform-uiextension-api/
where:
* xwiki-platform-uiextension-ui/: contains XWiki.UIExtensionClass page
* xwiki-platform-uiextension-api/: contains a ScriptService to get
UIExtension data + contains an EventListener that refreshes the UI
Extension Cache when an UIExtensionClass object is modified (this is for
performance reasons)
So how would this work exactly?
Each UI (skin, xwiki bundled application, user application, etc.) defines
these extension points that any other application can contribute to by
using the "type" field in an XWiki.UIExtensionClass instance? This would,
of course, mean a great deal of rewriting, but once done, it would be a
good investment.
To start with I'm proposing to have the following
fields for
UIExtensionClass:
* type: String, represents the type of the extension (for example for the
AllDocs needs, I'll use a "IndexTab" type (or "AllDocsTab" type)
* id: String, the technical name of the extension, which can be used for
example as suffix for HTML class or ids.
* name: String, the name of the extension, which can be used for
displaying. For example for the AllDocs needs, it would be used as the name
of the Tab
* content: Textarea: the content of the extension. For example for the
AllDocs needs, it would be used as the content to display when clicking on
a tab
Depending on the specifics of the extension point, the content gets treated
differently?
Also, I`m assuming this will generally be velocity/wiki syntax, right?
Another thing that might be useful (maybe in future iterations) would be
some kind of parameters that the extension could supply to its hook.
In your particular use case, a tab extension could say to the AllDocs page
that it wants its content to be loaded asynchronously, when the tab is
selected. Another case would be a menu extension that wants the menu item
to open in a new window when clicked or that wants to be placed before
entry X or after entry Y. Etc.
I'd like to implement this ASAP and thus stop
hardcoding UI Extensions
from now on.
The only downside I see is the performance penalty once everything starts
being extra extensible, but maybe using some smart caching (which you
already mentioned something about) we can limit the damage. The extension
content still needs to be evaluated every time (unless maybe otherwise
stated by the extension itself), but at least the list of extensions can be
easily cached.
Here's my +1
+1 if I understood it correctly.
Thanks,
Eduard
Thanks
-Vincent
PS: If you find a better than "uiextension" I'm all ears. A name without
"extension" would be great to not confuse it with our Extensions (and with
xwiki-platform-extension).
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
2:12 p.m.
New subject: [xwiki-devs] [VOTE] Creation of xwiki-platform-uiextension module
Hi Eddy,
On Nov 3, 2011, at 1:13 PM, Eduard Moraru wrote:
Yes, it's the user of the UIExtensionClass which decides what the content contains.
Yes that's the plan. As I mentioned the UIExtensionClass objects would be cached in
memory and the script service would return the cached values (it's an
"active" cache since it'll refresh automatically when a UIExtensionClass
object is modified).
Yes you did ;)
Thanks
-Vincent
Hi Vincent,
On Thu, Nov 3, 2011 at 12:56 PM, Vincent Massol <vincent(a)massol.net> wrote:
First le me say that I'm not planning this as something uber complex that may satisfy
all possible future needs. I'm taking a very pragmatic approach here which IMO solves
a lot of hardcoded issues we have today. We can optimize/refine it later on. I prefer to
that approach since the other approach hasn't worked in the past 5 years… ;)
Hi devs,
I'm implementing the LinkChecker UI and I want to be able to add a Tab in
AllDocs. Right now I've coded it with a hardcoded #if but I really hate
this.
So here's my proposal:
* Create the following modules:
xwiki-platform-uiextension/
|_ xwiki-platform-uiextension-ui/
|_ xwiki-platform-uiextension-api/
where:
* xwiki-platform-uiextension-ui/: contains XWiki.UIExtensionClass page
* xwiki-platform-uiextension-api/: contains a ScriptService to get
UIExtension data + contains an EventListener that refreshes the UI
Extension Cache when an UIExtensionClass object is modified (this is for
performance reasons)
So how would this work exactly? Each UI (skin, xwiki bundled application, user
application, etc.) defines
these extension points that any other application can contribute to by
using the "type" field in an XWiki.UIExtensionClass instance?
Yes.
This would,
of course, mean a great deal of rewriting, but once done, it would be a
good investment.
There's no need for any rewrite.
Whatever works will continue to work. OTOH of course it'll be nice if some existing
custom extension mechanisms were retrofitted to use this new UIExtensionClass. Now it
doesn't mean we should never allow custom extension mechanisms.
The idea is more than any part of the UI which needs to provide extension points would use
UIExtensionClass from now on if it fits its needs. For example I can think of the
Workspace Applications which needs a User profile extension point for the tabs and which
needs a Menu extension point for the top level Menu.
To start with
I'm proposing to have the following fields for
UIExtensionClass:
* type: String, represents the type of the extension (for example for the
AllDocs needs, I'll use a "IndexTab" type (or "AllDocsTab" type)
* id: String, the technical name of the extension, which can be used for
example as suffix for HTML class or ids.
* name: String, the name of the extension, which can be used for
displaying. For example for the AllDocs needs, it would be used as the name
of the Tab
* content: Textarea: the content of the extension. For example for the
AllDocs needs, it would be used as the content to display when clicking on
a tab
Depending on the specifics of the extension point, the content gets treated
differently? Also, I`m assuming this will generally be
velocity/wiki syntax, right?
Generally I'd say wiki syntax yes.
Another thing that might be useful (maybe in future
iterations) would be
some kind of parameters that the extension could supply to its hook.
In your particular use case, a tab extension could say to the AllDocs page
that it wants its content to be loaded asynchronously, when the tab is
selected. Another case would be a menu extension that wants the menu item
to open in a new window when clicked or that wants to be placed before
entry X or after entry Y. Etc.
Yes, good idea, we'll probably need to use a List field for that allowing the
extension to provide "key1=value1,key2=value2,…"
I'd like
to implement this ASAP and thus stop hardcoding UI Extensions
from now on.
The only downside I see is the performance penalty once everything starts
being extra extensible, but maybe using some smart caching (which you
already mentioned something about) we can limit the damage. The extension
content still needs to be evaluated every time (unless maybe otherwise
stated by the extension itself), but at least the list of extensions can be
easily cached.
Yes. Caching the rendered value would be another field in the UIExtensionClass for later.
Here's my
+1
+1 if I understood it correctly. Thanks,
Eduard
> Thanks
> -Vincent
>
> PS: If you find a better than "uiextension" I'm all ears. A name
without
> "extension" would be great to not confuse it with our Extensions (and with
> xwiki-platform-extension).
2:42 p.m.
New subject: [xwiki-devs] [VOTE] Creation of xwiki-platform-uiextension module
On 11/03/2011 09:12 AM, Vincent Massol wrote:
Yes, it's the user of the UIExtensionClass which decides what the content contains.
Yes that's the plan. As I mentioned the UIExtensionClass objects would be cached in
memory and the script service would return the cached values (it's an
"active" cache since it'll refresh automatically when a UIExtensionClass
object is modified).
Yes you did ;)
Thanks
-Vincent
Hi Eddy,
On Nov 3, 2011, at 1:13 PM, Eduard Moraru wrote:
I want to echo this sentiment, not just in this case but in general, there is a fine
balance between creating something that doesn't age well and not doing anything
because there might be a better way, both are dangerous.
Caleb
Hi Vincent,
On Thu, Nov 3, 2011 at 12:56 PM, Vincent Massol <vincent(a)massol.net> wrote:
First le me say that I'm not planning this as something uber complex that may satisfy
all possible future needs. I'm taking a very pragmatic approach here which IMO solves
a lot of hardcoded issues we have today. We can optimize/refine it later on. I prefer to
that approach since the other approach hasn't worked in the past 5 years… ;) Hi devs,
I'm implementing the LinkChecker UI and I want to be able to add a Tab in
AllDocs. Right now I've coded it with a hardcoded #if but I really hate
this.
So here's my proposal:
* Create the following modules:
xwiki-platform-uiextension/
|_ xwiki-platform-uiextension-ui/
|_ xwiki-platform-uiextension-api/
where:
* xwiki-platform-uiextension-ui/: contains XWiki.UIExtensionClass page
* xwiki-platform-uiextension-api/: contains a ScriptService to get
UIExtension data + contains an EventListener that refreshes the UI
Extension Cache when an UIExtensionClass object is modified (this is for
performance reasons)
So how would this work exactly? Each UI (skin, xwiki bundled application, user
application, etc.) defines
these extension points that any other application can contribute to by
using the "type" field in an XWiki.UIExtensionClass instance?
Yes.
This would,
of course, mean a great deal of rewriting, but once done, it would be a
good investment.
There's no need for any rewrite.
Whatever works will continue to work. OTOH of course it'll be nice if some existing
custom extension mechanisms were retrofitted to use this new UIExtensionClass. Now it
doesn't mean we should never allow custom extension mechanisms.
The idea is more than any part of the UI which needs to provide extension points would
use UIExtensionClass from now on if it fits its needs. For example I can think of the
Workspace Applications which needs a User profile extension point for the tabs and which
needs a Menu extension point for the top level Menu.
To start
with I'm proposing to have the following fields for
UIExtensionClass:
* type: String, represents the type of the extension (for example for the
AllDocs needs, I'll use a "IndexTab" type (or "AllDocsTab" type)
* id: String, the technical name of the extension, which can be used for
example as suffix for HTML class or ids.
* name: String, the name of the extension, which can be used for
displaying. For example for the AllDocs needs, it would be used as the name
of the Tab
* content: Textarea: the content of the extension. For example for the
AllDocs needs, it would be used as the content to display when clicking on
a tab
Depending on the specifics of the extension point, the content gets treated
differently? Also, I`m assuming this will generally be
velocity/wiki syntax, right?
Generally I'd say wiki syntax yes.
Another thing that might be useful (maybe in
future iterations) would be
some kind of parameters that the extension could supply to its hook.
In your particular use case, a tab extension could say to the AllDocs page
that it wants its content to be loaded asynchronously, when the tab is
selected. Another case would be a menu extension that wants the menu item
to open in a new window when clicked or that wants to be placed before
entry X or after entry Y. Etc.
Yes, good idea, we'll probably need to use a List field for that allowing the
extension to provide "key1=value1,key2=value2,…"
I'd
like to implement this ASAP and thus stop hardcoding UI Extensions
from now on.
The only downside I see is the performance penalty once everything starts
being extra extensible, but maybe using some smart caching (which you
already mentioned something about) we can limit the damage. The extension
content still needs to be evaluated every time (unless maybe otherwise
stated by the extension itself), but at least the list of extensions can be
easily cached.
Yes. Caching the rendered value would be another field in the UIExtensionClass for
later.
Here's my +1
+1 if I understood it correctly. Thanks,
Eduard
> Thanks
> -Vincent
>
> PS: If you find a better than "uiextension" I'm all ears. A name
without
> "extension" would be great to not confuse it with our Extensions (and with
> xwiki-platform-extension).
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
2:15 p.m.
New subject: [xwiki-devs] [VOTE] Creation of xwiki-platform-uiextension module
+1
Caleb
On 11/03/2011 06:56 AM, Vincent Massol wrote:
Hi devs,
I'm implementing the LinkChecker UI and I want to be able to add a Tab in AllDocs.
Right now I've coded it with a hardcoded #if but I really hate this.
So here's my proposal:
* Create the following modules:
xwiki-platform-uiextension/
|_ xwiki-platform-uiextension-ui/
|_ xwiki-platform-uiextension-api/
where:
* xwiki-platform-uiextension-ui/: contains XWiki.UIExtensionClass page
* xwiki-platform-uiextension-api/: contains a ScriptService to get UIExtension data +
contains an EventListener that refreshes the UI Extension Cache when an UIExtensionClass
object is modified (this is for performance reasons)
To start with I'm proposing to have the following fields for UIExtensionClass:
* type: String, represents the type of the extension (for example for the AllDocs needs,
I'll use a "IndexTab" type (or "AllDocsTab" type)
* id: String, the technical name of the extension, which can be used for example as
suffix for HTML class or ids.
* name: String, the name of the extension, which can be used for displaying. For example
for the AllDocs needs, it would be used as the name of the Tab
* content: Textarea: the content of the extension. For example for the AllDocs needs, it
would be used as the content to display when clicking on a tab
I'd like to implement this ASAP and thus stop hardcoding UI Extensions from now on.
Here's my +1
Thanks
-Vincent
PS: If you find a better than "uiextension" I'm all ears. A name without
"extension" would be great to not confuse it with our Extensions (and with
xwiki-platform-extension).
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
7 Nov
7 Nov
10:45 a.m.
New subject: [xwiki-devs] [VOTE] Creation of xwiki-platform-uiextension module
+1
Andreas
2011-11-03 11:56, Vincent Massol skrev:
Hi devs,
I'm implementing the LinkChecker UI and I want to be able to add a Tab in AllDocs.
Right now I've coded it with a hardcoded #if but I really hate this.
So here's my proposal:
* Create the following modules:
xwiki-platform-uiextension/
|_ xwiki-platform-uiextension-ui/
|_ xwiki-platform-uiextension-api/
where:
* xwiki-platform-uiextension-ui/: contains XWiki.UIExtensionClass page
* xwiki-platform-uiextension-api/: contains a ScriptService to get UIExtension data +
contains an EventListener that refreshes the UI Extension Cache when an UIExtensionClass
object is modified (this is for performance reasons)
To start with I'm proposing to have the following fields for UIExtensionClass:
* type: String, represents the type of the extension (for example for the AllDocs needs,
I'll use a "IndexTab" type (or "AllDocsTab" type)
* id: String, the technical name of the extension, which can be used for example as
suffix for HTML class or ids.
* name: String, the name of the extension, which can be used for displaying. For example
for the AllDocs needs, it would be used as the name of the Tab
* content: Textarea: the content of the extension. For example for the AllDocs needs, it
would be used as the content to display when clicking on a tab
I'd like to implement this ASAP and thus stop hardcoding UI Extensions from now on.
Here's my +1
Thanks
-Vincent
PS: If you find a better than "uiextension" I'm all ears. A name without
"extension" would be great to not confuse it with our Extensions (and with
xwiki-platform-extension).
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
8 Nov
8 Nov
1:11 p.m.
New subject: [xwiki-devs] [VOTE] Creation of xwiki-platform-uiextension module
+1
Thanks,
Marius
On Mon, Nov 7, 2011 at 11:45 AM, Andreas Jonsson <aj(a)member.fsf.org> wrote:
+1
Andreas
2011-11-03 11:56, Vincent Massol skrev:
Hi devs,
I'm implementing the LinkChecker UI and I want to be able to add a Tab in AllDocs.
Right now I've coded it with a hardcoded #if but I really hate this.
So here's my proposal:
* Create the following modules:
xwiki-platform-uiextension/
|_ xwiki-platform-uiextension-ui/
|_ xwiki-platform-uiextension-api/
where:
* xwiki-platform-uiextension-ui/: contains XWiki.UIExtensionClass page
* xwiki-platform-uiextension-api/: contains a ScriptService to get UIExtension data +
contains an EventListener that refreshes the UI Extension Cache when an UIExtensionClass
object is modified (this is for performance reasons)
To start with I'm proposing to have the following fields for UIExtensionClass:
* type: String, represents the type of the extension (for example for the AllDocs needs,
I'll use a "IndexTab" type (or "AllDocsTab" type)
* id: String, the technical name of the extension, which can be used for example as
suffix for HTML class or ids.
* name: String, the name of the extension, which can be used for displaying. For example
for the AllDocs needs, it would be used as the name of the Tab
* content: Textarea: the content of the extension. For example for the AllDocs needs, it
would be used as the content to display when clicking on a tab
I'd like to implement this ASAP and thus stop hardcoding UI Extensions from now on.
Here's my +1
Thanks
-Vincent
PS: If you find a better than "uiextension" I'm all ears. A name without
"extension" would be great to not confuse it with our Extensions (and with
xwiki-platform-extension).
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
13 Apr
13 Apr
1 p.m.
New subject: [xwiki-devs] [VOTE] Creation of xwiki-platform-uiextension module
Hi Vincent,
Any news on this?
Thanks,
Eduard
On Tue, Nov 8, 2011 at 2:11 PM, Marius Dumitru Florea <
mariusdumitru.florea(a)xwiki.com> wrote:
+1
Thanks,
Marius
On Mon, Nov 7, 2011 at 11:45 AM, Andreas Jonsson <aj(a)member.fsf.org>
wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
+1
Andreas
2011-11-03 11:56, Vincent Massol skrev:
> Hi devs,
>
> I'm implementing the LinkChecker UI and I want to be able to add a Tab
in
AllDocs. Right now I've coded it with a hardcoded #if but I really hate
this.
>
> So here's my proposal:
>
> * Create the following modules:
> xwiki-platform-uiextension/
> |_ xwiki-platform-uiextension-ui/
> |_ xwiki-platform-uiextension-api/
>
> where:
> * xwiki-platform-uiextension-ui/: contains XWiki.UIExtensionClass page
> * xwiki-platform-uiextension-api/: contains a ScriptService to get
UIExtension
data + contains an EventListener that refreshes the UI
Extension Cache when an UIExtensionClass object is modified (this is for
performance reasons)
>
> To start with I'm proposing to have the following fields for
UIExtensionClass:
> * type: String, represents the type of the
extension (for example for
the AllDocs needs, I'll use a "IndexTab"
type (or "AllDocsTab" type)
> * id: String, the technical name of the
extension, which can be used
for example as suffix for HTML class or ids.
> * name: String, the name of the extension,
which can be used for
displaying. For example for the AllDocs needs, it would be
used as the name
of the Tab
> * content: Textarea: the content of the
extension. For example for the
AllDocs needs, it would be used as the content to
display when clicking on
a tab
>
> I'd like to implement this ASAP and thus stop hardcoding UI Extensions
from now on.
>
> Here's my +1
>
> Thanks
> -Vincent
>
> PS: If you find a better than "uiextension" I'm all ears. A name
without "extension" would be great to not confuse it with our Extensions
(and with xwiki-platform-extension).
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
1:04 p.m.
New subject: [xwiki-devs] [VOTE] Creation of xwiki-platform-uiextension module
Hi Eddy,
On Apr 13, 2012, at 1:00 PM, Eduard Moraru wrote:
Hi Vincent,
Any news on this?
No news on my side, haven't done it yet. If you're interested to start the work,
go ahead, we need this ASAP:
* to reduce our technical debt
* to implement the ease of use theme for 4.1 and later, more specifically to allow
customizing the Menus for example.
I'm available to brainstorm on the topic if you're interested.
Thanks
-Vincent
Thanks,
Eduard
On Tue, Nov 8, 2011 at 2:11 PM, Marius Dumitru Florea <
mariusdumitru.florea(a)xwiki.com> wrote:
+1
Thanks,
Marius
On Mon, Nov 7, 2011 at 11:45 AM, Andreas Jonsson <aj(a)member.fsf.org>
wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs +1
Andreas
2011-11-03 11:56, Vincent Massol skrev:
> Hi devs,
>
> I'm implementing the LinkChecker UI and I want to be able to add a Tab
in
AllDocs. Right now I've coded it with a hardcoded #if but I really hate
this.
>
> So here's my proposal:
>
> * Create the following modules:
> xwiki-platform-uiextension/
> |_ xwiki-platform-uiextension-ui/
> |_ xwiki-platform-uiextension-api/
>
> where:
> * xwiki-platform-uiextension-ui/: contains XWiki.UIExtensionClass page
> * xwiki-platform-uiextension-api/: contains a ScriptService to get
UIExtension
data + contains an EventListener that refreshes the UI
Extension Cache when an UIExtensionClass object is modified (this is for
performance reasons)
>
> To start with I'm proposing to have the following fields for
UIExtensionClass:
> * type: String, represents the type of the
extension (for example for
the AllDocs needs, I'll use a "IndexTab"
type (or "AllDocsTab" type)
> * id: String, the technical name of the
extension, which can be used
for example as suffix for HTML class or ids.
> * name: String, the name of the extension,
which can be used for
displaying. For example for the AllDocs needs, it would be
used as the name
of the Tab
> * content: Textarea: the content of the
extension. For example for the
AllDocs needs, it would be used as the content to
display when clicking on
a tab
>
> I'd like to implement this ASAP and thus stop hardcoding UI Extensions
from now on.
>
> Here's my +1
>
> Thanks
> -Vincent
>
> PS: If you find a better than "uiextension" I'm all ears. A name
without "extension" would be great to not confuse it with our Extensions
(and with xwiki-platform-extension).
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
4531
days inactive
4693
days old
10 comments
6 participants
participants (6)
-
Andreas Jonsson -
Caleb James DeLisle -
Eduard Moraru -
Marius Dumitru Florea -
Thomas Mortagne -
Vincent Massol