Hi devs,
I wanted to show you what work has been done until now on the Google
Gadgets Integration, talk a bit about the next steps and ask for
feedback. I put up the gadgets work on the incubator, so you can take
a quick look.
Mostly I'm interested in the minimum subset of features and changes
that I need to make in order to have something worth integrating in a
future release.
Macro Directory: (for all Wiki Macros and Java Macros)
http://incubator.myxwiki.org/xwiki/bin/view/Macros/
Macro Description Page:
http://incubator.myxwiki.org/xwiki/bin/view/Macros/Macro?id=wc99
Dashboard Macro Test:
http://incubator.myxwiki.org/xwiki/bin/view/MacrosTest/DashboardTest
The dashboard example contains 3 macros imported from Panels, like
Last Members, My Recent Modifications and Blog Categories, and 1 macro
imported from a Google Gadget: World Clocks. (I named it w99)
Import Google Gadget as Macro Form:
http://incubator.myxwiki.org/xwiki/bin/view/Macros/GoogleGadgetsImport
WYSIWYG Integration:
- easily edit all Google Gadget Macros parameters/user preferences (if
inserted alone on the page)
- if a macro is inside the Dashboard macro, you don't have access to
editing its parameters. Ideally, in the future this kind of
interaction would be nice to have:
http://incubator.myxwiki.org/xwiki/bin/view/Mockups/GadgetsIntegrationPropo…
(Test both of the above here:
http://incubator.myxwiki.org/xwiki/bin/view/MacrosTest/DashboardTest)
I'm planning to work next on:
- AJAX requests to update dashboard state after each drag&drop action
(modify the content of the dashboard to reflect the new order of the
gadgets
- Add Thumbnail and Screenshots support for Macros
- Nice UI for Dashboard and Macros Directory (already asked Caty for help here)
More work after that:
- Add Macros(Gadgets) to a Dashboard (either from the Directory and/or
through WYSIWYG editor)
- Convert all Panels to Wiki Macros (Question here: What happens with
the panel headers? Do I transform them into headings like in the Last
Members, My Recent Modifications, Blog Categories examples? If so, how
would they be placed on the side, in the empty shell containers to
keep looking like they do now? (
http://incubator.myxwiki.org/xwiki/bin/view/Mockups/GadgetsIntegrationPropo…
or http://incubator.myxwiki.org/xwiki/bin/view/Mockups/GadgetsIntegrationPropo…
?)
- Create types for Wiki Macro parameters: boolean, enum, (int), string
(very inconvenient right now for enum types for gadgets with a lot of
options -- e.g. see time zone parameters (up_tz1) for World Clock
macro --> problem would be nicely solved with a Select)
- Allow custom number of columns for Dashboard
Questions:
- Should dashboard cells have titles? If so, what happens to the
titles of Panel origin Macros? (see discussion a little more above)
- Is the current syntax of dashboards OK?
{{dashboard}}
1 {{members/}}
1 {{myrecentmodifications/}}
2 {{blogcategories/}}
3 {{wc99 title='Another Clock Gadget' w='280' h='280'
up_tz1name='Bucharest' up_tz2name='Paris' up_tz1='RO' up_tz2='FR'/}}
{{/dashboard}}
, where each line represents a cell, the first number being the column
number, one blank space and the the content of the cell. For a given
column, the order of appearance is important, being treated as a stack
(one cell above another).
* Keep in mind:
- the lines need to be easily update by many AJAX requests issued at
each Drag&Drop on the dashboard (both their order, and also the column
numbers)
- content available in wiki editor
- currently does not allow multiple lines for one cell (would a lot
more complicated for the AJAX updates)
- currently has no title - do we need a title??
SVN:
- https://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-gadgets/
(Java Components)
- https://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/gadgets/ (XAR)
Thanks for the feedback,
Anamaria
I appreciate:
- Proposal 7 by Sorana Secu, it communicates the idea of
collaboration(see X) - I don't like the choice of colours.
- Proposal 15 by Vishal Battula, it communicates a feeling of joy and
it's easy to remember.
- I like the font and colour choices made by Ecaterina(proposal 1-2).
I think that the idea of collaboration is suggested by the word Wiki, then
my vote goes to Proposal 15 but I think we can adopt
the font and colours picked by Ecaterina, if it's possible to make a merge
:D.
Giuseppe.
Hi all :), I'm following this discussion about XWiki homepage redesign. I
have to say that I like much the second proposal made by Ecaterina
here.<http://incubator.myxwiki.org/xwiki/bin/view/Improvements/XWikiOrgProposal2>I
want to give just an idea for the "fat" footer, I don't know if this
has
been discussed but I think (imho) that fat footer should be displayed when a
user want more information about (community, project, or something else) I
think an example explains better, look at kde.org if you want more
information about some topic in the tab bar, you go with cursor there and it
shows more details; as vincent said it seems like a duplication of
information in the upper part, and footer. I found this resoruce about web
design that could be useful:
webStyleGuide<http://www.webstyleguide.com/wsg3/index.html>
.
Giuseppe.
Hi there,
I'd like to start a overhaul of the xwiki.org home page + a first
level navigation overhaul.
Today:
* Home page = list the different products
* First level nav = the ecosystem panel
Problems:
* We now have a single product: XE and all the others are actually
modules that plugin into the main products. Hence we shouldn't focus
on other products so much IMO.
* I'd like to view xwiki.org as a forge of projects. Today our top
level projects are the ones listed here: http://svn.xwiki.org/svnroot/xwiki/
* The main page should be more dynamic and show some news and activity
instead of being static
* People are confused by the top level navigation vs the second level
one because they both use panels and it's not easy to differentiate them
Proposal:
* Use a horizontal top level navigation with the following items (from
left to right):
- Overview or Home (the main page)
- Platform
- Projects (when clicked will list all top level projects) - We could
have the list of subproject available as submenu items too (as it's
done on http://jboss.org/)
- Support (when clicked will explain the various ways to get support
including mailing list/forum, irc/jabber, FAQ & listing companies
offering commercial support)
- Contribute or Community (when clicked we'll get dev.xwiki.org)
- Playground
This means that the panels on the right will become the second level
navigation and the content will depend completely on where you are on
the site.
* Have some facilities links in the header on the right:
- News
- Downloads (as a visible button maybe)
* On the home page:
- Have a nice diagram of the xwiki platform that shows how XE, XE
modules are positioned on the platform so that people understand right
away that xwiki is a collaborative web dev platform
- Have a Highlight box with XE so that users looking for a full-
fledged wiki can quickly see it and click on it + maybe one featured
screenshot of an entry from the References page that would be
different every time the page is refreshed (this could encourage
people to add references + provide a link to the references directly)
- Have a Featured project box and list 3-4 featured projects (XE, XEM,
XEclipse, XOffice for ex to start with)
- Have some news:
-- latest 5 blog post titles
-- latest 5 code zone additions (all snippet, plugins, macro, apps,
etc included)
-- latest 5 mailing list threads subjects (with links to our nabble
forum)
We could not have any second level navigation for the home page in
order to have more space for displaying the elements above.
WDYT?
If/when we're ok in term of content maybe Cati (or anyone interested)
could provide some mockups of what it could look like.
Thanks
-Vincent
PS: Let's not get bogged down with details at this point. I think
what's important is to make progress and refine later on. What's
important is that we agree on the broad lines at this stage.
Hi devs,
I have this code:
var content = '$content';
I need to escape the string before it is written to the response because
otherwise the JavaScript code can be easily messed up. Is there any
utility function/macro in the platform that I can use for this purpose?
I couldn't find anything so I wrote a small velocity macro:
#**
* Escapes the given velocity string before it is assigned to a
JavaScipt variable.
* The following characters are escaped: \, ", ' and \n.
*
* @param $string the string to be escaped for JavaScript
*#
#macro(escapeForJavaScript $string)$!{string.replace('\',
'\\').replace('"', '\"').replace("'", "\'").replace("\u000D\u000A",
"\u000A").replace("\u000A", '\n')}#end
This code can be optimized in Java by traversing the string only once.
Should I add a $util.escapeForJS method or the velocity macro to the
platform?
Thanks,
Marius
The XWiki development team is pleased to announce the release of XWiki
Enterprise 2.3 Milestone 1.
Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download
This is first milestone of the XWiki Enterprise 2.3 version.
Main changes from 2.2.3:
* New annotation feature
* New color theme editor
* Anonymous commenting with captcha
* Lots of bugs fixes
For more information see the Release notes at:
http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise23M1
Thanks
-The XWiki dev team
Hi devs,
Currently it's not really possible to know that a wiki as been deleted
(there is possible hack based on wiki descriptor but it's not more
than a hack).
The direct issue with that is that anyone having a document based
cache can't update it. One good example is Lucene, if you delete a
wiki you will still have the related page in the Lucene index. It also
means in a cluster that other instances will not know a wiki has been
deleted and you can still find pages of this wiki in the documents
cache of the other instances.
I propose to create a WikiCreatedEvent (to be consistent, and we could
use that to do some wiki initialization tasks) and WikiDeletedEvent
events.
WDYT ?
Here is my +1.
The related jira issue is http://jira.xwiki.org/jira/browse/XWIKI-3966
--
Thomas Mortagne
Hi devs,
I just added a new project, xwiki-portlet, to contrib/sandbox. Its final
target is to handle the integration of an XWiki Enterprise instance
inside a JSR286 compatible portal.
My current approach is to dispatch portlet requests from a portlet
(DispatchPortlet) to an XWiki Enterprise instance running on the same
context path. I use a servlet filter to catch these requests on the
servlet side and to adjust them. I'm rewriting the XWiki URLs from the
response, if content type is text/html, into portlet URLs so that the
user can navigate through XWiki pages without leaving the portal. XWiki
URLs are mapped to portlet URLs (action/render/resource) through
configuration (e.g. /bin/download/ prefix is mapped to a resource
request type).
The current code is not well documented and there are no tests. It's
more or less a proof of concept. I'm still investigating if the current
approach covers all the use cases.
In order to be able to fully integrate XWiki into a portal we must
rewrite some of XWiki's UI to ensure it is isolated from the rest of the
portal when in portlet mode. This implies:
* making sure the CSS doesn't affect content outside of the XWiki
container (the container needs to be defined)
* namespacing HTML element ids
* namespacing JavaScript global variables
The last two points are required to allow two instances of the XWiki
portlet to be present on the same portal page and have different state.
Thanks,
Marius