Hi guys,
Some time back we started improving title handling, I'd like that we continue this and I'm proposing some further improvements below:
* Make the title field contain wiki syntax (same as the content field) instead of just velocity
* Make the title field a textarea so that we can have more than 1 line
* Display a textarea of 1 line initially (to preserve space) but enlarge the textarea visibility by several line on the first Enter keypress in the field
* Stop trying to extract title content from the doc content
* Have a backward compat param to still support the old mode, but have it off by default in 4.2/4.3
<side>
* Introduce a {{i18n}} macro (or {{translate}}, or …)
</side>
Advantages:
* Same as the content field - More consistency
* More power since we use wiki syntax and we can use any script language
* Removes the WTF symptom when a user edits a page having velocity script in the title since they'll see it displayed in WYSIWYG mode with the title content evaluated
* Removes the uncertainty about title extraction (for ex if some macro generates headings) but still allow it if it's really needed - Since the user will be able to write scripts in the title textarea and those scripts can extract stuff from the doc content if they really need it
* We'll be able to add a l18n macro and thus display the title translations nicely in the wysiwyg editor
WDYT?
Thanks
-Vincent
>> Hy,
> >
> > I wish to contribute to xwiki.
> >
> > I forked xwiki-platform and when I execute the clone command I get the following error:
> >
> > error: unable to create file xwiki-platform-core/xwiki-platform-application-mana
> > ger/xwiki-platform-application-manager-api/src/main/java/com/xpn/xwiki/plugin/ap
> > plicationmanager/core/doc/objects/classes/XObjectDocumentDoesNotExistException.j
> > ava (No such file or directory)
> > fatal: cannot create directory at 'xwiki-platform-core/xwiki-platform-classloade
> > r/xwiki-platform-classloader-protocols/xwiki-platform-classloader-protocol-attac
> > hmentjar/src/main/java/org/xwiki/classloader/internal/protocol/attachmentjar': N
> > o such file or directory
> >
> > Can you help me or tell me how to get xwiki-platform on my computer for work.
> >
> > Best regards.
>
> Are you on a Windows machine?
>
> --
> Sergiu Dumitriu
> http://purl.org/net/sergiu/
Yes my machine is on Windows Seven. I have another on on ubuntu if necessary
Hello Friends,
> What about having a drop down of recently used spaces under the space
> menue
> and wikis under wiki menue on the top.. It currently has document index
> only.
That's a good idea I think. I'll do one (better?) and put it under the
quicklinks, since it is pretty relevant there and will be more visible,
what do you guys think?
Thanks. I'll take some time to look into this deeper. Maybe you could start
> committing the row HTML/CSS/JS in a repository on your github account, so
> that it's easier to collaborate on.
Sounds good: https://github.com/jssolichin/xorange
Unfortunately, I have yet integrate to XWIKI, but for the most part most
the skin is as it was in the mock up (desktop). The menu, the issue I had
with the scrollbar, and so forth has been resolved. Again
http://jssolichin.com/xwiki
will show the latest version of where I am at.
My next step is to begin down scaling--testing compatibility with tablet
(which should not take too long (starting with the 2 column collapse, line
breaks etc. )), then finally to mobile and enabling the hidden sidebar
function.
There are some closer refinements such as font detail etc. that I will
begin to compile as I do the next few steps and then I will clear them out
together. The community can help me to find these refinements as well.
Interestingly, this small library has just been published today:
> http://fat.github.com/coffin/
> It might be interesting for you as either inspiration or even support for
> implementation.
That is awesome. I will definitely look into this. Thanks for tip.
> By the way, the js library smart client (Isomorphic smart client) has UI
> > components that are device sensitive.The library is made with an object
> > oriented way trying to follow a normal java/c# like oo fasion(because
> > originaly Js has different kinds of concepts as OO.).I think there were
> > some methods to override when you need additional customizations to the
> UI.
> >
> >
> http://demo2.openbravo.com/openbravo/org.openbravo.demo.loginpage.security/…
> > This ERP application almost completely uses Smart Client.
> > http://planet.openbravo.com/?p=48278 UI archi.
> > I just said this because there is smart client in the XWiki provided
> libs.
> > Don't waste your time on it, if it is not relevant.
> >
> ... [show rest of quote<http://xwiki.475771.n2.nabble.com/GSoC-Responsive-Skin-td7526728i20.html#>
> ]
> Indeed, smartclient is not going to be appropriate here. It's a
> heavyweight
> widget library for building complex, enterprisy desktop-like UI clients ;
> where we need something "minimalist" as a framework for a responsive web
> page.
Sasinda, thanks, that is really cool. Although I agree with Jerome that
it's not the best for this, it is good to know that it is out there. Thank
you for chiming in!
Personally Arch Linux and Open JDK, but that should not change anything.
Yea, i know technically it shouldn't. But i've been having a few problem
with my present distro, so i'm trying to remove any differences and what
not. Thanks for the info.
You can drop the hsqldb,jetty profile for the skin, it does not have such
> profile.
> Note that I've publised the skin on extensions.xwiki.org :
> http://extensions.xwiki.org/xwiki/bin/view/Extension/Lyrebird+Skin See
> the
> instructions at the bottom to install it on a XWiki instance.
> Unfortunately
> right now skins cannot be installed right from the extension manager, but
> that will be possible in the future.
Great! Thank you for that clarification.
Thanks again for all the help everyone,
Jonathan Solichin
Hy,
I wish to contribute to xwiki.
I forked xwiki-platform and when I execute the clone command I get the following error:
error: unable to create file xwiki-platform-core/xwiki-platform-application-mana
ger/xwiki-platform-application-manager-api/src/main/java/com/xpn/xwiki/plugin/ap
plicationmanager/core/doc/objects/classes/XObjectDocumentDoesNotExistException.j
ava (No such file or directory)
fatal: cannot create directory at 'xwiki-platform-core/xwiki-platform-classloade
r/xwiki-platform-classloader-protocols/xwiki-platform-classloader-protocol-attac
hmentjar/src/main/java/org/xwiki/classloader/internal/protocol/attachmentjar': N
o such file or directory
Can you help me or tell me how to get xwiki-platform on my computer for work.
Best regards.
Hello friends and Jerome,
Thanks for the response.
> Can you describe us the issue you are trying to address regarding this
> sidebar and the associated javascript ?
> It looks like unnecessary complexity for me. Aren't media queries just
> enough to have the sidebar resize/move when the viewport size changes ?
> I'd like we keep things simple as much as possible, so tell me if I'm
> missing something.
So the reason i am using javascript, is because although media queries
handle viewport changes, its adaptation is does not completely work in some
scenarios. Eg. the sidebar scrolling area (for when there's a lot of things
on that topic), would require a fix height to get the overflow to work (or
else it will stretch along and will no longer be a "fixed sidebar").
However, if we have a fixed height, during viewport size change it would
cause an issue (of it no longer being a fixed sidebar since it's longer
than the viewport). i think there is a couple other issue that prevented me
from using straight up html/css, but I can't think of it at the moment. Let
me know if you have a better suggestion!
Additionally, I want the sidebar to be resizable at least a desktop/tablet
level where there is a good amount of width so that if you're more concern
on reading the additional info, you can get more space for it. The great
thing (or the idea behind) the sidebar was to allow supplemental info to be
viewed along with the content (think Microsoft SmartGlass if you've learned
about that aha). But the issue is that the size of a sidebar is not always
optimal for reading long contents, so i want it to be resizable
to accommodate. So this resizing thing will also be done via jQuery.
In any regards, I have been to resolve most of the issue and it seems to
work well atm (let me know any bugs that i missed). Again you can check out
the working demo that i'm working on at: http://jssolichin.com/xwiki .
Unfortunately the code behind is a bit ugly right now, and need to be
cleaned up. My next step is to finish up the navigation (the mouse over
event revealing different sections and the icons indicating content on each
section) and making it look like the mock up.
Most of use are using either OSX or Linux. Are you following
> http://dev.xwiki.org/xwiki/bin/view/Community/Building ?
I am. Which distro? and oracle or openjdk for java?
What module are you trying to build exactly ? Most of the times you don't
> need to build everything, but just the module(s) you are working on (and
> possibly the final distribution, like XE).
I'm trying to build your Lyrebird (from its source) to learn about creating
VMs. I think I am able to build it now actually. I am going into the
lyrebird directory and running "mvn clean install -Phsqldb,jetty" to build
it. But I am still not sure what to do next? Can you point me in the right
direction?
Thank you again!
Jonathan Solichin
Hi devs,
Lately, I`ve been working on being able to filter the events that are
displayed by the Activity Stream macro.
I`ve implemented both the JavaScript and the no-JavaScript version and I`d
like your vote on whether we want to merge it into master or not.
Please have a look over the pull request [1][2] and let me know if you spot
any bad decisions or bad code :)
Here's my +1
Thanks,
Eduard
----------
[1] https://github.com/xwiki/xwiki-enterprise/pull/27
[2] https://github.com/xwiki/xwiki-platform/pull/55
The XWiki Development team is pleased to announce the 4.1.1 bug fix release.
Download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download
And review the release notes here:
http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWikiEnterpris…
This release fixes the following issues:
* XWIKI-7943 Impossible to save very large pages in jetty
* XWIKI-7940 Conflict reported when same existing document is already in the database and there is no previous official version of the XAR extension
* XWIKI-7939 Merge conflict resolution UI fails when there is no previous version
* XWIKI-7938 Conflict reported when an extension document have attachment when installing a xar
* XE-1190 Add suggest in Debian packages
* XE-1189 Debian package fail to upgrade
* XCOMMONS-201 class java.lang.StackOverflowError in LogQueue.error under some conditions
Thanks to the developers for getting these issues fixed promptly and thanks to the users
for your helpful bug reports and your patience.
Caleb
Hi devs,
While fixing http://jira.xwiki.org/browse/XWIKI-7889 I introduced an
API to resolve and serialize entity references on the client side
(JavaScript code). See
https://github.com/xwiki/xwiki-platform/commit/cfa8ec3315a32fed875949ff21a5….
XWiki Explorer tree has an input displayed at the bottom where you can
type a _pseudo_ entity reference which is parsed and the specified
entity is selected in the tree. The basic problem (very simplified)
was that this reference was parsed on the client side and the parsing
code did not handle special characters in entity name (no escaping).
Of course, I had to options:
* add a service (REST?) to resolve/serialize the reference on the server or
* (as I did) port part of the code from xwiki-platform-model (with
unit tests!) to JavaScript to be able to resolve/serialize entity
references on the client side.
There are pros and cons for each option but for me the main reason was
that it is painful to modify xwikiexplorer.js to make AJAX requests
each time you type into that input box (the tree node is selected as
you type). An almost complete rewrite was needed and since we're
looking to replace that tree I thought the second option was better.
Would be great if you can review my commit. I'm interested in the API
naming and places where I put the JS code. Also, I'm not sure where to
document the new API (that is if no one is against it).
Thanks,
Marius