8 Mar
2011
8 Mar
'11
10:19 p.m.
On Mar 8, 2011, at 9:35 PM, Marta Girdea wrote:
On Tue, Mar 8, 2011 at 9:21 PM, Vincent Massol
<vincent(a)massol.net> wrote:
I was going to say that we don't need pseudo versions for this since we just need to
keep it in memory till the save button is applied.
However the pseudo version solution is interesting as backup solution, i.e. if the page
crashes you still get your "unsaved" content available. So indeed it would solve
2 needs at once.
Thanks
-Vincent
On Mar 8, 2011, at 8:53 PM, Ludovic Dubost wrote:
Just a gentle reminder and "call for votes" on this issue:
http://jira.xwiki.org/jira/browse/XWIKI-500
My proposal about using view mode is not to be in "edit" mode automatically.
My proposal is to have the "edit" button maybe more visible as well as
"Add Widget", and more importantly to have the "edit" button not load
the "inline" mode, but load in place.
Most importantly the "save" buttons don't mean anything as adding a gadget
adds an XWiki object and is permanent. Same with moving and removing gadgets. That changes
the object right away.
Actually this is a bug that we need to fix. It's absolutely not normal that when you
add objects in the object editor the objects are added even if you cancel the edit > Thanks
> -Vincent
>
>> So we need to "remove" the "save" actions as they won't
mean anything.
>>
>> Ludovic
>>
>>
>> Le 08/03/11 18:07, Sergiu Dumitriu a écrit :
>>> On 03/08/2011 05:57 PM, Marta Girdea wrote:
>>>> On Tue, Mar 8, 2011 at 4:01 PM, Luca Anca<lucaa(a)xwiki.com>
wrote:
>>>>> On Sat, 2011-03-05 at 12:44 +0100, Ludovic Dubost wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I've tried the dashbord on 3.0 snapshot and could not make
the "Add
>>>>>> Gadget" function work on an empty dashboard.
>>>>>> From what I see the issue seems to be in the wysiwyg code. I
got the
>>>>> no, it's dashboards code, I forgot to handle the case when the
column
>>>>> where the gadget should be added doesn't actually exist.
>>>>>
>>>>>> dialog box from the wysiwyg, when clicking on Insert Gadget"
I got an
>>>>>> exception:
>>>>>>
>>>>>> uncaught exception: Class$dF: One or more exceptions caught, see
full
>>>>>> set in UmbrellaException#getCauses
>>>>>> at
>>>>>> function nr(){try{null.a()}catch(b){return b}}
>>>>>>
>>>>>> This issue seemed to only happen with an empty dashboard macro
(with not
>>>>>> gadget yet added).
>>>>>>
>>>>>> I think we need to work on two things for each feature that we
are
>>>>>> developping:
>>>>>>
>>>>>> 1/ Having a status of where we are:
>>>>>>
>>>>>> In the case of Dashboard, I think that's updating this page:
>>>>>>
http://dev.xwiki.org/xwiki/bin/view/Design/Gadget+Scenarios+Prioritized
>>>>> I updated the table. There could be new cases, I guess, to comprise
the
>>>>> missing things (like adding a column when editing, or others a
like),
>>>>> but I prefer to use Jira issues for these. WDYT?
>>>>>
>>>>>> 2/ Write a test plan and have Sorin include the testing of new
features
>>>>>> in his testing.
>>>>>> For that he needs to know how to test and what is supposed to be
>>>>>> there/not there.
>>>>>>
>>>>>> Concerning the development priorities, I think for the next
period of
>>>>>> development on the dashboard we need to focus on wiring the UI
for
>>>>>> "beginners", making it easy for them to create their
first dashboard. In
>>>>>> my view this is in priority:
>>>>>>
>>>>>> - Create page with a dashboard macro (In the Add Menu in XE)
>>>>>> - Go to edit more
>>>>> What's "edit more"?
>>>>>
>>>>>> (I'm still convinced that we need the dashboard
>>>>>> editing in "view" mode and not in "inline"
mode)
>>>>> What do others think?
>>>>> Knowing that the current edit in inline mode has a few limitations:
>>>>> * remove gadget will be saved immediately, not when the user clicks
>>>>> "save". If the user says remove gadget, confirms the remove
and then
>>>>> clicks the "cancel" button in the edit form, the remove
will still be
>>>>> saved.
>>>>> * same for add gadget.
>>>>>
>>>>> The way I see the two possibilities:
>>>>> A) "View mode edit" will save on every change
>>>>> B) "Edit mode edit" (implemented as inline edit, now) will
save
>>>>> everything at the end (current implementation but with the
limitations
>>>>> fixed).
>>>>>
>>>>> So, WDYT?
>>>> -1 for A)
>>>>
>>>> I'm definitely for B) "Edit mode edit", not only for
consistency, but
>>>> also for avoiding surprise side effects when interacting with the
>>>> dashboard.
>>> Same for me. Users tend to just move things around, accidentally click
>>> the mouse, and then "things just broke by themselves".
>>>
>>>>>> - Add a column in your dashboard
>>>>>> - Editing a dashboard
>>>>> you mean editing a gadget? as in the parameters of that gadget?
>>>>>
>>>>> Also, I would add to this list, potentially at the top:
>>>>> - finalizing the structure of the dashboard / gadgets objects, so
that
>>>>> we don't have migration in the next releases (e.g. if we decide
to add a
>>>>> field in the gadget object to identify which is the dashboard of
that
>>>>> gadget, in case there are multiple dashboards on one page, we should
do
>>>>> it now).
>>>>>
>>>>> Thanks for the feedback,
>>>>> Anca
>>>>>
>>>>>> Also for the 3.1 timeframe I think we need to have some
brainstorm to
>>>>>> add some more "Dashboard" friendly macros/gadgets to
make dashboards
>>>>>> more usefull and interesting for users, but that's another
story.
>>>>>> Right now I think the most important is that we agree on the
priorities
>>>>>> for the next step and that for 3.0 we have a simple but coherent
>>>>>> dashboard feature.
>>>>>>
>>>>>> Ludovic