23 Nov
2010
23 Nov
'10
10:52 a.m.
On 11/23/2010 09:05 AM, Vincent Massol wrote:
If it's about wysiwyg editing the generated stuff, I don't think we can
ever fix it. I mean dashboard wysiwyg (drag and drop gadgets to set
positions, click a button to edit parameters, etc). Think about:
{{velocity wiki=true}}
{{dashboard}}
#set($column = "{{spaces /}}")
((($column)))
{{/dashboard}}
{{/velocity}}
How would you ever be able to re-produce that piece of wiki syntax from
an HTML?
It's easy. The wysiwyg sees the velocity macro and since wiki=true the content is
wiki and thus the wysiwyg would allow you to edit the content in wysiwyg mode, thus seeing
visually the dashboard macro which you can click on and edit.
Now I've just realized that you may not be talking about the wysiwyg editor but
simply about click on edit in the dashboard in view mode. I guess that's solvable too
with several strategies:
1) store the dashboard macro cells/columns in a Dashboard Object on the page. When
editing it it's those objects that are changed. This makes it very easy to modify a
dashboard.
lemme remember (and dig in the mails) why we didn't like this solution.
It was a proposed solution in the design document which we've discussed
at one point http://dev.xwiki.org/xwiki/bin/view/Design/GadgetIntegration .
On Nov 23, 2010, at 12:18 AM, Anca Luca wrote:
this would be solution no 3) which I don't like that much, because it
would make the gadgets inside too aware of the fact that they are part
of a dashboard.
On 11/22/2010 03:34 PM, Vincent Massol wrote:
I thought there was a discussion about using a scope parameter suggested by jerome (but I
don't know if we concluded about it or not in the end).
On Nov 22, 2010, at 1:03 PM, Anca Luca wrote:
if you mean on the Main.Dashboard, it's because you need to detect
whether it's a global dashboard or a space dashboard, and pass the
parameters with the current space to the activity and tagcloud macros. Hi devs,
** short story: **
for XE-722 we'd need to implement the main and spaces dashboards separately
** long story: **
currently we're using the Main.Dashboard page to include in various
contexts to create a dashboard (global or space level). Namely, it is
used in Main.WebHome (to create the global dashboard) and in all the
*.WebHome pages to create the space dashboards.
With the implementation of the dashboard macro, now there is a simpler
(and better) way to create dashboards, but with a restriction, they
should not be generated by a velocity script (because something which is
generated programatically cannot be wysiwyg edited).
Why is there velocity script around the dashboard macro? Because of this,
the Main.Dashboard cannot be used anymore as is (since it needs velocity
to differentiate between space or global dashboard).
Note that this is a wysiwyg limitation that we need to fix over time anyway. 2) or navigate the XDOM tree to find the dashboard
macro and change the order of the columns/cells according to how the user has moved them
around or how he added new content.
this is the part which cannot work, because even if I produce the
modified XDOM, how would I ever be able to produce the velocity code
that would generate that modified XDOM to re-produce the wiki syntax?
Think about:
{{velocity wiki=true}}
{{dashboard}}
(((
#if($isSpaceDashboard)
{{spaceindex /}}
#else
{{spaces /}}
#end
)))
{{/dashboard}}
{{/velocity}}
which is very similar to what we'd have on the Main.Dashboard.
Thanks,
Anca
With solution 1) you'd start by creating an empty dashboard, then go in edit mode and
add content. Adding content would create DashboardItem objects (for example).
... just a wild idea... ;)
Thanks
-Vincent
ok, I agree with this argument.
however, this might be an issue in conjunction with Jerome's arguments
for keeping Main.Dashboard as space dashboard for compatibility reasons
(which I agree with), since we might need to implement 3) (see my cons
for proposal 3).
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
** options: **
1) have the dashboard macro directly in the Main.WebHome and not in an
included document.
I don't like this too much. We need a Main.Dashboard page IMO since users will want
to customize their home page I think and still have a link to the Dashboard page in the
quick links menu for example.
Let's say I'm 0 on this.
which is what I said above, but I was just wondering whether it's a
bigger problem for main webhome dashboard than it is in general. Because
that's the standard type of content that is displayed on the main
webhome and one might think that one customization should be done
regardless of the language.
Thanks,
Anca
The bad part is that when a translation is
edited,
it's only that translation which sees the changes, but this is an issue
in general
I don't get this part. This is true whether you have an {{include}} or a
{{dashboard}} macro.
I need more info about my questions above to answer the points below.
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 2) for the space dashboards, there are 3
possibilities:
a) leave it all in the Main.Dashboard document to be included in all
space dashboards ('backwards compatible')
b) leave it all in a document to be included but rename it to
Main.SpaceDashboard (to be semantic)
c) remove any document for this purpose, and write the dashboard macro
call directly in the space webhome, since now it should be a lot easier
to do that and also to customize it (7-8 lines of code but no wysiwyg,
yet), potentially create a template provider for this.
Note that a) and b) require a way for the recent activity and tagcloud
macros to realize that it's the current space they need to use as the
scope, without actually passing the space because that would mean
velocity scripting, again. This is not necessarily a bad thing, though.
Besides overcoming this, c) has also the advantage that the dashboard
will be in the document itself, and not included (I don't have yet a
straightforward solution for wysiwyg editing included dashboards). The
drawback of c) is that it will be impossible to customize all the space
dashboard at once, you'd need to develop a bit to provide that capability.
I'd +1 for 1) and I'd choose 2c).
WDYT?
Thanks a lot,
Anca
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs