13 Jul
2012
13 Jul
'12
12:23 p.m.
Hello friends,
Just a quick update. I have implemented the history, improved the
livetables/xwikitabbars and fixed the attachment bugs and other
sidebar/global bugs. Unfortunately, I still haven't figured out the
comments issue yet.
As mentioned in my last email, I was researching the best way to make
tables more responsive. This applies very much to the history docextras as
well. Traditionally the historyinline have been very horizontal--something
that does not fit with the sidebar. So for the implementation, i opted for
a modal box. with a link in the sidebar to open it (
http://23.21.87.183:8080/xwiki/bin/view/Main/WebHome#history). It still
uses the filament tables, such that the table would scale nicely. I know
that the modal box is a bit different than the rest of the docextras, but i
felt like it was the best way since reading the table is the optimal way to
see the history. Though I was also considering this:
http://css-tricks.com/examples/ResponsiveTables/responsive.php. I was
wondering what you would think if I made the history tables in this way, or
whether we should brainstorm for a better resolution.
On another note of the filament tables, the way that the table response is
by prioritizing which columns is most important. As less screen real estate
is available, it removes the less important columns. These columns,
however, can still be toggled back via a button. Presently I made the
decisions of which columns seems to be the most important. Eg (each bracket
represents a level). For the history: [from, to, version] [date,comment],
[author, editor]. For document index: [page, space], [date] [author,
editor]. What are your thoughts on this? Alternatively, we can create a
settings page so the administrator can choose the priorities?
Finally relevant links for the skins:
Live instance: http://23.21.87.183:8080/xwiki/bin/view/Main/WebHome
Implementation source: https://github.com/jssolichin/xo5
Original (proof of concept) source: https://github.com/jssolichin/xorange
Thanks all
Jonathan Solichin
On Tue, Jul 10, 2012 at 12:45 AM, Jonathan Solichin <jssolichin(a)gmail.com>wrote;wrote:
Hello friends,
You could re-write the whole macro in your template (as a macro - or not).
This way you can change it without overriding the
whole macros.vm. Also
know that you can macros.vm "empty" and override macros here selectively,
instead over overloading everything - at least that's as far as I can
remember.
Ah, so I only need to write in the macros i specifically need in my
macros.vm (that is, my macros.vm will not overwrite the template macros.vm,
but will load on top of it?). I tested this and deleted all the macros
except the one I changed, and it seems to be working. However, I wanted to
make sure, since macros.vm is a big file and that I am not messing anything
up. Thanks for the tip.
I realized that there is a bug in the skin that prevented some pages from
being displayed correctly, or being redirected incorrectly. Those pages
would redirect to "[correct url]?viewer=comments" and I realized it was
because of the way the commentsinline.vm is integrated into the skin. If my
attempt to solve the bug and understanding of xwiki is correct, this is a
result of the redirectIfActionNotView macro. Specifically, I think that
"#if(!$requestedByAjax && $xcontext.getAction() != 'view'
&&
$xcontext.getAction() != 'get')" on line 85 of commentsinline.vm is causing
the redirect issue because the comments are no longer being requested by
ajax in my skin (it loads everything and the skin just scrolls to the
correct place). This seems to be confirmed as if I remove the ! in front of
$requestedByAjax, the document would show up correctly. However, this does
not seem to be the correct solution, since if I do this, the page won't be
refreshed if I add a comment (manually refreshing the page reveals that the
comment has been successfully added). I tried deleting $requestedByAjax and
permutting different conditions to load this correctly, but to no avail.
Can you point me in the right direction for an elegant solution at this?
Also, I am planning to make the livetables work responsively (since they
are an integral part of xwiki, and it seems to break the responsiveness of
the skin). Presently, my research is pointing me to this solution:
http://filamentgroup.com/lab/responsive_design_approach_for_complex_multico….
What are your thoughts/comments?
Finally, this was sort of brought up in the semantics thread, but I was
wondering whether I should also skin applications (eg. blog)? If I
understand correctly, the skin files do not touch upon them? Actually, I
guess the css will. Should I just skin them through css, or should I do
more?
Thank you again!