Hi devs,
This is a thread to discuss what kind of title behavior we want in the future. I've listed some topics I consider open below. Could you give me your opinion about them?
1) Should we force titles to be mandatory by default
2) Should we merge page names and titles in the UI (ie only expose titles and compute page names based on it)
3) Do we want titles to be generated from content if the title is empty or not. If 1) is agreed then there'll always be a title set so this is probably not needed
4) Should we allow wiki syntax in the title field and make that field a textarea rather than a single line string (to allow scripts to generate titles, this is useful for applications for example). Note that currently the title field can only contain velocity and no wiki syntax AFAIK.
Any other topic to discuss related to titles?
Thanks
-Vincent
Hi,
First of all, I am very excited that Xwiki Community accepted my proposal
"Auto Completion in Content Editors", and thanks for everyone that helped me
a lot during the application time.
Second, I will talk about something I have done these days, and then talk
about the problems that confuse me.
1. I have setted up an Linux(Ubuntu 11.04)+Git+maven(2.2.1) environment for
developing Xwiki projects. Everything goes well in this step.
2. And I have downloaded the source code of xwiki-enterprise from github,
build it up, and got xwiki-enterprise-jetty-hsqldb-3.1-SNAPSHOT.zip file
under distribution folder, unzip it and run the start_xwiki.sh, and visit
http://localhost:8080, it is successful to see the xwiki page.
3. I have searched some issues related to WYSIWYG editors, and I finnally
chose two for optionals:http://jira.xwiki.org/jira/browse/XWIKI-4471 and
http://jira.xwiki.org/jira/browse/XWIKI-4179.
Problems:
1.Building XE takes a long time about more than half an hour, if I am
working on XE, for example fix some bugs of it, and want to compile and run
it as soon as possible to see the results, have an hour would be a very long
time for waiting each time. I know maybe the second time for building XE
will be much faster than the first time, but it still take some time to
build the whole codes, it must slow down the efficiency to debug my code.
So anyone can tell me how should I do, or is there any best prictices for
debuging and compling the code based on XE.
2. About the selected two issues, one is to add a small new feature, and the
other one is to fix a bug, I want to ask for some advices about which issue
would be ok, and could you give me some more informations for these two
issues.
--
Best wishes,
许凌志(Jame Xu)
MOE KLINNS Lab and SKLMS Lab, Xi'an Jiaotong University
Department of Computer Science and Technology, Xi’an Jiaotong University
Hi,
First of all I would like to thank XWiki for selecting me to the
Google Android Client for XWiki project through the GSOC. As a
beginning I'm currently studying on building XWiki public repositories
like xwiki-enterprise, xwiki-manager, xwiki-platform etc. so that I
can get the domain knowledge. I hope to fix some jira issues in these
repositories. Can anybody tell me some other way to get proper
understanding in XWiki appropriate to this Android project?
Thank you,
Chamika Weerasinghe
Hi devs,
I have a small issues with the comments on github: they are invisible to the xwiki dev team right now. We used to comment on commit mail diffs which made the comments available to everyone (including non developers) following the notifications/devs lists. Right now we have started using github for commenting but this means I don't see anymore when stuff get commented. I have to go to github specifically and look out for comments.
Is there a better way combining our lists + github to keep the open collaboration aspect of reviews?
Thanks
-Vincent
fyi: http://feedly.com/k/fZWfhP
Exceprt from the release notes:
Highlights include:
• Fixed numerous bugs that break the compressor and/or the resulting minified files.
• Added documentation on what exactly the minifier does and also which CSS hacks it tolerates.
• There’s a JavaScript port of CSS min in case it’s more suitable for your build process.Here’s also a test web UI that uses the JavaScript port, where you can experiment with the minifier.
• A significant number of new tests added (but you can add even more).
• Safe handling of some CSS features that are getting more adoption such as media queries and CSS3 transforms.
We could upgrade maybe.
Thanks
-Vincent
We are going to end up releasing M1 with a *lot* of broken tests, I have not seen anyone volunteer
to fix or look at any yet.
see: http://dev.xwiki.org/xwiki/bin/view/Community/ReleasePlans#HFixfailingtests
Going forward to M2 we are going to need a major stability drive and I think this is a good time to
introduce the "stable branch" as per the branching strategy laid out here:
http://nvie.com/posts/a-successful-git-branching-model/
#1. Bug fixes are committed against the stable branch and forward ported to the development branch.
#2. New features are committed against the development branch and then merged back to the stable
branch only after we are assured they have not broken any tests or introduced bugs.
Here's my +1
Caleb
I offered to take over the release since Jerome was unable to do it and right now we have 38 test
failures.
16 selenium1 tests,
6 selenium2/ui-tests
16 webstandards tests.
We have 3 options:
1. We can release now and accept bugs in the release.
2. We can have volunteers to take over tests and get them passing for tomorrow so tomorrow I can
release.
3. We can opt to postpone the release. If I work on these alone I expect it to take about 1 week as
long as nobody commits code which introduces further regressions.
I don't think postponing the release is wise at this point and #2 is contingent upon volunteers
claiming ownership of specific tests so I think #1 is the lesser of the evils.
Do I hear any objections/volunteers?
Caleb
Hi devs,
I'm going to start working on a XWiki extension repository.
The idea is to provide a repository of extension like you can do with
maven repository but with a lot more possibilities like commenting on
extensions, grades, statistic, direct search...
The (work in progress) reference design page is
http://dev.xwiki.org/xwiki/bin/view/Design/ExtensionManagerXWikiRepository.
the general idea is to have the following modules:
- server (jar): basically a collection of rest resources allowing to
manipulate extensions
- server UI (xar): allow to administrate the repository itself
- client (jar): extension manager repository handler for XWiki
repository which communicate with server module using REST
the plan is to provide for 3.1 a first version with at least the
following characteristics:
* server side
** extension are in wiki pages (even extension themself as
attachments, it's not the design long term goal it's simply the
quickest for 3.1)
** REST interface will provide what extension manager already support
in maven repositories plus:
*** search extensions (probably just simple search for now)
** UI will have a livetable of extension and not much more
** will try to integrate it to extension.xwiki.org
* client side
** extension manager API will be added with search capabilities
** add a search filed in the existing extension manager admin UI
** the XWiki repository handler module of course
Thanks
--
Thomas Mortagne
Hello,
I want to download the source code in order to build from source.I cant
find a zip file which contains the source.Can someone help me?
Thank you!:D