Hi Anthony,
I also liked your proposal and I would be happy to help you with the HTML,
CSS, Javascript and Velocity part for the Calendar application.
Welcome! for all the GSoC students ;)
Raluca.
Hi
I`m trying to figure how to do this, i`m using the excel plugin and i want
to have a select box to select the sheet to display:
<form id="form1" name="form1" method="post" action="">
<label>
<select name="sheet" id="sheet">
<option value="03-20-2009">03-20-2009</option>
<option value="03-27-09">03-27-09</option>
<option value="04-03-2009">04-03-2009</option>
<option value="4-10-2009" selected="selected">4-10-2009</option>
</select>
</label>
</form>
</label>
<p>
<label>
<input type="submit" name="button" id="button" value="Submit" />
</label>
</p>
$xwiki.ExcelPlugin.getTable("Status.xls", "4-10-2009", "A3-H20")
The "4-10-2009" should be the value from the select...
Any ideas?
Hi
I`m trying to figure how to do this, i`m using the excel plugin and i want
to have a select box to select the sheet to display:
<form id="form1" name="form1" method="post" action="">
<label>
<select name="sheet" id="sheet">
<option value="03-20-2009">03-20-2009</option>
<option value="03-27-09">03-27-09</option>
<option value="04-03-2009">04-03-2009</option>
<option value="4-10-2009" selected="selected">4-10-2009</option>
</select>
</label>
</form>
</label>
<p>
<label>
<input type="submit" name="button" id="button" value="Submit" />
</label>
</p>
$xwiki.ExcelPlugin.getTable("Status.xls", "4-10-2009", "A3-H20")
The "4-10-2009" should be the value from the select...
Any ideas?
Hello everybody!
My name is Cristina Scheau (cristinaS from IRC). I will work on "XWiki
Integration with OpenOffice", mentored by Sergiu Dumitriu. My actual design
page is : <http://dev.xwiki.org/xwiki/bin/view/Design/XWikiIntegrationWithOpenOffice>
http://dev.xwiki.org/xwiki/bin/view/Design/XWikiIntegrationWithOpenOffice
It will be improved. If someone has suggestions about it, please let me
know.
The project will be an Open Office extension. In a nutshell, my action plan
is:
1. Doing some research about the OpenOffice SDK API
2. Discussing with the community about the software archtecture
3. Developing a GUI for XOO extension
4. Implementing a wizard for connecting to a XWiki server and a xwiki
navigational panel
5. Implementing the core classes that will be used in the future
development
6. Implementing the functionalities: edit existing XWiki pages and add new
XWiki pages from OpenOffice
7. Implementing the functionalities: download and upload attachments
8. Implementing : editing attachments supported by Open Office
9. Refining the GUI and adding new small functionalities
10. Improving the project using the feedback from the users.
Thank you very much for accepting me!
Have a great day,
Cristina
On Wed, Apr 22, 2009 at 1:40 AM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote:
> Hello Google Summer of Code students,
>
> First of all, congratulations on your applications and your activity during
> the selection period, and welcome in the XWiki development team.
>
> Before guiding the accepted students to their next steps, we'd like to
> thank again all those who showed interest in XWiki for this Summer of Code.
> We had an impressive number of good applications this year, with
> professional approaches and interesting ideas, and it was very difficult to
> choose only 6. Unfortunately, some very good students, with great potential,
> were not accepted. So, to those interested in getting involved anyway,
> without Google's implication, I renew the invitation to put your ideas in
> practice under the guidance of the community. Even though the money will be
> missing, you can still take advantage of the other GSoC benefits: learning
> new things, gaining experience, earning recognition, etc [
> http://www.catb.org/~esr/writings/cathedral-bazaar/homesteading/].
> If you would like to do that, please let us know by replying to this mail.
>
> For the accepted students, here are some getting started hints:
>
>
> Community bonding period
>
> According to the program timeline [
> http://socghop.appspot.com/document/show/program/google/gsoc2009/timeline],
> the next month (April 20th - May 23rd) is to be used for community bonding.
>
> The first thing to do, sometime this week, is to present yourself and your
> project on the dev list, so that everyone knows who you are and what to
> expect from you.
>
> Also, you should continue getting acquainted with the code, the practices
> and the developers. Please make sure you all read and understand the
> following - very useful - documents:
> - http://purl.org/xwiki/community/
> - http://purl.org/xwiki/dev/
> - http://platform.xwiki.org/xwiki/bin/view/Features/
>
>
> Mentorship
>
> We prefer open mentorship. While your assigned mentor is the one officially
> in charge with your guidance, almost all interaction should be done 'in the
> open' as much as possible, on the IRC channel or on the mailing list. You
> should choose the communication medium according to the importance of the
> matters to be discussed: naturally, the less important issues are to be
> discussed on IRC, while the design decisions, important progress
> announcements and testing/feedback requests go on the list. This way, the
> community is informed on the evolution of your project, and other developers
> can come up anytime with useful ideas and suggestions. Moreover, if your
> mentor is hit by a bus (the bus factor [
> http://en.wikipedia.org/wiki/Bus_factor]<http://en.wikipedia.org/wiki/Bus_factor%5D>),
> another developer can take his place with little effort.
>
>
> Communication
>
> Sitting alone in your room, working secretly on your project is definitely
> a bad approach. However, please keep in mind that too much communication can
> also be harmful, as it distracts the others from their own work. You need to
> be able to communicate just right:
> - provide meaningful information about your progress,
> - ask the community's opinion on non-trivial design or implementation
> decisions
> - avoid waisting a lot of time on a problem, when a more experienced
> developer (or a student that fought the same problem) could quickly provide
> you an answer; however, do try to find the answer yourself at first.
>
> Wrong: "Where do I start? What do I do now? And how do I do that? Is this
> good? It doesn't work, help me!"
> Right: "Since a couple of hours ago I get a strange exception when building
> my project, and googling for a solution doesn't seem to help. Looking at the
> error, I think that there's a wrong setting for the assembly plugin, but
> nothing I tried works. Can someone please take a look?"
>
> Subscribe to the devs list (if you didn't do this already), and start
> monitoring the discussions. It is also recommended to subscribe to the users
> list, but not mandatory. The notifications list is a little too high volume
> and technical for the moment, but it is a great knowledge source.
>
> We have set up a wiki on the community farm for you to organize your ideas
> and log your progress: http://gsoc.myxwiki.org/ . Each student must
> register on this wiki, create and organize a space for the project, with a
> blog where the evolution will be described. Currently the wiki is pretty
> empty, but it will grow.
>
>
> Development process
>
> The project's lifecycle is NOT design -> implementation -> testing ->
> documentation. [
> http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/]
>
> We invite you to adopt a test driven development [
> http://en.wikipedia.org/wiki/Test-driven_development][http://www.amazon.com…<http://en.wikipedia.org/wiki/Test-driven_development%5D%5Bhttp://www.amazon…>]
> approach and to experience agile development [
> http://www.amazon.com/dp/0596527675/]. After the first coding week, you
> must have some code that works. It won't do much, of course, but it will be
> the seed of your project. Every functionality will be validated by tests.
> The code must be properly tested and commented at the time of the writing
> (don't think you'll do that afterwards, because in most cases you won't).
>
> We will create the proper projects in the xwiki sandbox, and we encourage
> you to do __at least__ weekly commits (ideally, if you are well organized,
> you should be able to commit code that works daily, so try to aim at daily
> commits). This way, the code can be properly reviewed, and any problems can
> be detected before they grow into something too difficult to fix. One big
> code blob committed at the end, no matter how good it may seem, is a failure
> at several levels.
>
> A simple way of having something functional in the first week is to prepare
> the maven build, which will give you the first unit test for the first
> class.
>
>
> Next steps, in a nutshell
>
> - Get more familiar with the code and development process and try to master
> Maven, JUnit, Selenium, component driven development, ...
> - Continue fixing a few small issues, chosen so that they are __related to
> your project__ -- This will help you get more familiar with the code your
> project needs to interact with.
> - Refine and organize the ideas concerning your project (use the wiki), and
> write several use case scenarios.
> - Start writing the first piece of code for your project.
>
> At the end of the community bonding period, you should have a clear vision
> of the project, well documented on the wiki, you should have the build
> infrastructure ready, and you should be pretty familiar with the existing
> code you will need to interact with. And, of course, you should be familiar
> with the community and the way we communicate.
>
> Good luck, and may we all have a great Summer of Code!
> --
> Sergiu Dumitriu
> http://purl.org/net/sergiu/
>
Hi,
I'm implementing semantic properties in XWiki Syntax 2.0
http://jira.xwiki.org/jira/browse/XWIKI-3320
I've done the wikimodel part and I'm now wondering how what XHTML we
should generate in the XHTML renderer (and thus what XHTML should the
wysiwyg handle).
Here's an example input:
%%property1 (((
%%property2 **value2**
%%property3 value3
)))
Right now one solution I've found is to serialize the property content
in xwiki syntax 2.0 and output it as a comment in the XHTML renderer:
<!--startproperty %%property1 (((
%%property2 **value2**
%%property3 value3
)))--><!--stopproperty-->
(note: we could have <!--property--> instead of start/stopproperty,
that's a detail)
Then the XHTML parser would use the xwiki syntax 2.0 parser on the
content of the comment to generate events.
Since it's not very trivial to serialize to xwiki syntax in the XHTML
renderer I'd like to know what you think or if you have a better idea.
I guess we could also do something like:
<div class="'xwiki-semantic property1">
<div class="xwiki-semantic property2>
<p>
<strong>value2</strong>
</p>
</div>
<div class="xwiki-semantic property3">
<p>
value3
</p>
</div>
</div>
Note: we would use span for inline semantic properties instead of divs.
And then have a CSS with display:none for ".xwiki-semantic"
The advantage of this latter solution are:
* Easier to implement for the XHTML renderer and XHTML parser
* Is in line with HCARD if we want to support it (and we probably do),
see
http://jira.xwiki.org/jira/browse/XWIKI-3320?focusedCommentId=39554&page=co…
WDYT?
Thanks
-Vincent
Hi,
I am new to XWiki. I was trying to set up virtual wiki using DB2 v9.1 or
v9.5.
First I installed XWiki Enterprise Manager on Tomcat and set up DB2
following the "Installation DB2" guide. After that I tried to create virtual
wikis using XEM. But when I clicked "Create new wiki" link in the XWiki
Enterprise Manager and enter "wikitest" as wiki identifier, it kept
prompting that "A database with this identifier already exists". But the
fact is that I don't have a database named "wikitest" on my DB2. Then I
found out that no matter what I typed in the wiki identifier text box, it
all prompted "A database with this identifier already exists". This prevents
me from creating a virtual wiki.
Can anyone help me out? Thanks very much in advance!
BTW, I can successfully create virtual wikis on MySQL and access them.
Hi devs,
right now we need to hit enter twice in a row to create a new paragraph.
Although I strongly pushed this implementation back in the day, it is
proving to be counter-intuitive for almost all users. After a review of a
number of other tools (including OpenOffice & online text editors) & reading
of posts on the topic, I came to the conclusion that we'd better come back
to the previous behavior for the enter key:
- Hitting enter once creates a new paragraph
- Hitting caps + enter creates a new line in the same paragraph
When writing, users tend to write a number of sentences (most of the time
between 3 and 7 of them) and then hit enter to create a new paragraph. The
issue sometimes encountered is that an user writes a single line, then hits
enter to find out that a lot of spacing is entered between both lines. This
issue can easily be fixed through CSS in the default XWiki Enterprise
distribution (we could use OOo as a source of inspiration for the respective
line heights between 2 lines & 2 paragraphs - right now I'd say the height
between 2 paragraphs is a bit too big).
Additionally, this would "fix" the "issue" currently encountered by users
when they input 2 lines and try to make one of them a title:
- User inputs line of text, hits enter, inputs 2nd line
- User puts caret at the end of first line and selects "Title 1"
- Both lines are turned into a title -> weird
This behavior is unexpected from an end-user point of view and would be
fixed by coming back to the previousbehavior for the enter key.
WDYT?
Guillaume
PS: I'm really sorry about the additional work incurred by my initial lack
of understanding of the role of paragraphs
--
Guillaume Lerouge
Product Manager - XWiki
Skype ID : wikibc
http://guillaumelerouge.com/
Hi,
We've had an interesting discussion with Thomas about the need to
introduce a new onRawText() event in the rendering module to replace
the current begin/endXML() events.
Here's the need (discovered by Ludovic):
* In some cases we want to inject rendered content directly in the
renderer's output. For example there are some cases where we want to
inject HTML directly (in order to bypass parsing)
What we propose:
* Remove the current XML events
* Add a onRawText(Syntax syntax) event and a corresponding RawBlock
block. A raw text is text injected directly in the rendered output
without any parsing/modification. Note that the content depends
completely on the rendered used hence the Syntax parameter.
* Add a new {{raw syntax="syntaxId"}} macro so that users can inject
content in the few cases where it's needed
* Modify the HTML Macro to use RawBlock blocks instead of XMLBlock.
Also add a new "clean=true|false" parameter (defaut is to clean). When
clean = true, we pass the content to the HTML cleaner.
<Implementation note>We still need to parse the content when
wiki=true. We generate RawBlock blocks when we have startElement/
endElement/CDATA/Comment xml parser events.</Implementation note>
This solves a number of issues:
* We have a generic way to inject rendered content directly for the
special cases when it's needed (ex: the user really wants to inject
invalid HTML such as META tags in the body content)
* We remove the XML events which were a bit weird to have in the first
place.
Note that we'll probably need to add some new events in the future
such as one for demarcating a set of blocks (which would translate in
DIV or SPAN in the XHTML renderer for example). This is needed for
example for the Box Macro which is currently using XMLBlock but that's
not completely correct.
WDYT?
Thanks
-Vincent