xwiki-devs July 2012

xwiki-devs@xwiki.org

33 participants
98 discussions

[xwiki-devs] Release managers wanted for 4.2M1 and 4.1.3

by Vincent Massol

Hi eveyrone, Today is our release date for 4.2M1 (see http://enterprise.xwiki.org/xwiki/bin/view/Main/Roadmap). We also need to release 4.1.3 ASAP. Thus we need two Release Managers (RM)? Any volunteer? Thanks -Vincent

12 years, 5 months

Re: [xwiki-devs] [GSoc] Responsive Skin - markup semantics

by Jonathan Solichin

Hi Jerome, friends, > * Would it make sense to use <aside> for the right sidebar ? The aside is actually only for the comments, attachments, history and info sections of the sidebar only. The reason behind this is that according to html5 specs: > > The aside element represents a section of a page that consists of content that is tangentially related to the content around the asideelement, and which could be considered separate from that content. Such sections are often represented as sidebars in printed typography. ( http://html5doctor.com/understanding-aside/) which I thought is appropriate for those sections. > > * I've seen you've used <article> as an overall wrapper. Wouldn't <section> > be more appropriate, with articles implemented within the content of the > document ? (BTW this leads to the question of how this would translate in > wiki syntax. So far there is no such notion built right in - though .it > could be implemented with macros). The reason I used article as an overall wrapper for the "main content" (the stuff with the white background), according to the html5 specs: > > "The article element represents a component of a page that consists of a self-contained composition in a document, page, application, or site and that is intended to be independently distributable or reusable, e.g. in syndication. This could be a forum post, a magazine or newspaper article, a blog entry, a user-submitted comment, an interactive widget or gadget, or any other independent item of content." ( http://html5doctor.com/the-article-element/) I thought this is appropriate since the entire "main content" is the self contained part of the page that can be independent of the other parts (like menu, asides, sidebars etc.) The use of section I thought is appropriate because each gadgets is in a way a section/part of the overall article, and of the sidebar. > > "The section element represents a generic document or application section" (http://html5doctor.com/the-section-element/) These are just my thoughts on the components of a webpage of xwiki, however. Do you think this is not the correct interpretation of the xwiki parts? Thanks for looking into the code! Jonathan Solichin

12 years, 5 months

Re: [xwiki-devs] [GSoC] Responsive Skin

by Jonathan Solichin

Hello friends, > But actually I wouldn't advise to overload macros.vm, from experience it > becomes a maintenance hell over the long term. I can see how that can happen. Unfortunately, I think it was the best way to do it, because I converted the menu and sub menu system to a list instead of span to work with the css hovers. Additionally, isn't it more semantic this way, or was there a reason it is this way that I did not realize? Regarding this change, my only observation is an usability one. What are > the most common actions a user will want to do on this page? Navigate away > from the page? See comments? See informations? > IMO edit action should not be the last in the menu. Maybe you could move > edit and export to be more visible or closer to the content. A quick > solution would be to put the items in the beginning of the list and not at > the end. This way the user doesn't need to scroll all the way down for > them. Makes sense. The change has been made in the implementation (xo5) There are, actually, a couple of mandatory files XWiki will look for (like > view.vm, edit.vm, etc. all those that are referenced from struts actions > in > java) ; but if they aren't found, XWiki will look for them upstream : in > the parent skin (if there is one), then in templates/ folder. So nothing > really is mandatory for a skin to implement, you just override what you > need to. If you look into Lyrebird you'll there are far less templates > than > in colibri. It's due both to the fact that for some feature the skin just > uses the colibri version (because it works fine) and the fact some > templates in lyrebird aggregates what is several templates in colibri, to > make it simpler. This is a good explanation, and confirmed what I thought. Thanks! All those are legitimate questions :) it takes some getting used to and > some experience to grasp the whole skin architecture. For lyrebird I knew > where I wanted to go, so I implemented that by either : > * adapting (CSS tweaks, reuse of velocity macros, etc.) colibri features > (ex: breadcrumb), or > * re-writing the feature entirely (ex: top navigation bar, edit mode > controls/inputs) > But I'm a bit biased since I know the whole structure of colibri well > enough to arbitrate this quickly. Thanks for the insights No you're right fundamentally you don't need a maven build since for now > skins can't be distributed as extensions (but will in the future). But it > makes things easier anyway for releasing (creating a SCM tag with an > associated version), for creating the zip, etc. > Practically, the build could also permit to minify JS and CSS files, > filter > out some resources, or do some other operation required before > distribution. Ok, I will keep this is mind as I progress further. Progress: a lot of the skin has been implemented (enough to work mostly?). I am still having a bit of issues that I got stuck on, however. - The biggest head scratchier I have right now is the historyinline.vm that I am putting in the sidebar. All the other components of docextra.vm seems to be working fine. But when I turn on the line that pulls in historyinline.vm, the contents in mainContentArea disappears? I tried messing with historyinline.vm, but I can't figure out what is causing it. The history ui and controls works fine, it's just the document oddly disappears. (The way I am turning it off/on is in the sidebar.vm, I put a "!" on line 22 to reverse the if-- causing history to disappear if the document asks for it. The current historyinline.vm is straight from the template). Any idea? - Second, I can't find any mention of the gadget wrappers or anything to do with gadgets in the templates? Did I miss it, or is it placed elsewhere. The reason is I want to add a <section> wrapper as per html5, since each "gadgets" are a "section" of the articles/content, correct? I will touch upon this in email regarding semantics. As always, source (for implementation) is at: https://github.com/jssolichin/xo5 Thank you again for all the help and insights! Jonathan Solichin

12 years, 5 months

[xwiki-devs] [GSoC] Solr multilingual support.

by savitha sundaramurthy

Hi devs, Here are my thoughts on the configuration for multi lingual support. Solr uses different analysers and stemmers to index wiki content. This is configured in a XML file, schema.xml. The wiki content with english language is indexed with text_en field type whereas french with text_fr field type. The language of the document is fetched and appended to the field. ( fieldName +"_"+ language : title_en, fulltext_en, space_en ). Configurations below:  <fieldType name="text_en" class="solr.TextField" positionIncrementGap="100"> <analyzer type="index"> <tokenizer class="solr.StandardTokenizerFactory"/> <filter class="solr.StopFilterFactory" ignoreCase="true" words="stopwords.txt" enablePositionIncrements="true" /> <filter class="solr.SynonymFilterFactory" synonyms="index_synonyms.txt" ignoreCase="true" expand="false"/> <filter class="solr.LowerCaseFilterFactory"/> <filter class="solr.EnglishMinimalStemFilterFactory"/> </analyzer> </fieldType>  <fieldType name="text_fr" class="solr.TextField" positionIncrementGap="100"> <analyzer> <tokenizer class="solr.StandardTokenizerFactory"/>  <filter class="solr.ElisionFilterFactory" ignoreCase="true" articles="lang/contractions_fr.txt"/> <filter class="solr.LowerCaseFilterFactory"/> <filter class="solr.StopFilterFactory" ignoreCase="true" words="lang/stopwords_fr.txt" format="snowball" enablePositionIncrements="true"/> <filter class="solr.FrenchLightStemFilterFactory"/>   </analyzer> </fieldType> In the case of a document having multilingual text, say english and french. There is no way to find the list of languages used in the document. Is it good to use a language detection tool, http://code.google.com/p/language-detection/ to get the list of languages, if they are more than two use a multilingual field type ? title_ml, space_ml, fulltext_ml, ml for multilingual.  <fieldType name="text_ml" class="solr.TextField" positionIncrementGap="100"> <analyzer> <tokenizer class="solr.StandardTokenizerFactory"/>  <filter class="solr.LowerCaseFilterFactory"/> <filter class="solr.StopFilterFactory" ignoreCase="true" words="lang/stopwords_fr.txt" format="snowball" enablePositionIncrements="true"/> <filter class="solr.EnglishMinimalStemFilterFactory"/> <filter class="solr.FrenchLightStemFilterFactory"/> <filter class="solr.SpanishLightStemFilterFactory"/> </analyzer> </fieldType> The list of analysers should match the languages supported by XWik instance. Am planning to use language detection only to check whether text from multiple languages exist. Will investigate if its possible to configure the analysers on the fly based on the languages returned by the language-detection tool. Please suggest,if this is a right approach ? -- Thanks, Savitha.s

12 years, 5 months

[xwiki-devs] [GSOC] Basic Solr Implementation

by savitha sundaramurthy

Hi All, I have come up with the basic Solr Search Component. Have included features such as hit highlighting. You can find a running instance of the component here. http://ec2-50-19-181-163.compute-1.amazonaws.com:8080/xwiki/bin/view/Search… Below is the link to the documentation and the progress of the project. http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/SOLRsearchcomponent API http://dev.xwiki.org/xwiki/bin/view/Design/SOLRSearchIntegration Basic multi lingual support, and basic facet search are in progress to be implemented for the coming week. Kindly give your suggestions. -- Thanks a lot, Savitha.s

12 years, 5 months

[xwiki-devs] [VOTE] Move Chart plugin to contrib/retired

by Vincent Massol

Hi devs, I'm proposing to move the chart plugin from oldcore and to move it to contrib/retired (without moving the history). The rationale is: * It's old and I'm pretty sure it's not fully working (I doubt that the chart wizard works well for example). It has no automated tests at all actually. * It's been replaced by the XWiki Rendering Chart macro Here's my +1 Thanks -Vincent

12 years, 5 months

[xwiki-devs] [VOTE] Use document author instead of context user in wiki macro listener

by Thomas Mortagne

Hi devs, Currently the wiki macro is looking at context user when a wiki macro is modified. This is causing a lot of complexity and misunderstanding so I would like to change that to look at document author instead. * all we at at startup is document author anyway so if you restart that what XWiki will look at to register the macro so I don't see the point in not doing the same thing at runtime * context user makes more complex to make sure wiki macro are properly registered in background thread like clustering (http://jira.xwiki.org/browse/XWIKI-7318) and extension manager jobs (http://jira.xwiki.org/browse/XWIKI-8004) WDYT ? Here is my +1 -- Thomas Mortagne

12 years, 5 months

[xwiki-devs] [VOTE] Fix typo in org.xwiki.properties.PropertyDescriptor#getFied()

by Thomas Mortagne

Hi devs, There is a typo in org.xwiki.properties.PropertyDescriptor#getFied() so in order to fix it I need to deprecate it and add new getField() method. Since addinf a new method makes me add an CLIRR exclude, here is the VOTE. Note that in practice this interface is supposed to be implemented only by internal class so it's not going to break anyone. WDYT ? Here is my +1. -- Thomas Mortagne

12 years, 5 months

[xwiki-devs] [GSoc] Responsive Skin - markup semantics

by Jerome Velociter

Hi Jonathan, everyone, I've checked out the markup of the skin. I have two questions : * Would it make sense to use <aside> for the right sidebar ? * I've seen you've used <article> as an overall wrapper. Wouldn't <section> be more appropriate, with articles implemented within the content of the document ? (BTW this leads to the question of how this would translate in wiki syntax. So far there is no such notion built right in - though .it could be implemented with macros). WDYT ? Jerome -- Jérôme Velociter Winesquare http://www.winesquare.net/

12 years, 5 months

Re: [xwiki-devs] [GSoC] Responsive Skin

by Jonathan Solichin

Hello friends, > - not every entry in the toolbar should have a counter, for example Main, > History, Info is confusing to have counters. The only relevant counters > IMO > are the Comments, Annotations, Attachments; oops, copy and paste carelessness. Thanks - the .nav-icons section could work as a toolbar and every action could > take you to the appropriate anchor (for example: clicking on the > history-clock icon should take you to #history) > - when you are using the .nav-control, the items in the navigation have > counters near the type, like "Attachments 3". Would be nice to have this > counter too when manually scrolling the navigation, like have the counter > not only on .attachments-link but also on #attachments-wrapper h2 Good calls, implemented. - in recent versions of XWiki (since 4.0) Comments are merged with > Annotations - good to know that :) * I think by default Annotation and Comments UIs should be merged, just > like they are now on a standard XE. Thank you, for the notice. > - "Main" section content: "Last Modified", "Created", "Tags" can be put in > the "Information" section although the last editor could be put near the > page title somewhere in order to be able to scan rapidly; - you could have a separate "Actions" section that contains page actions: > edit, export, etc. I moved the modified/created/tags into the information-- makes more sense. I created two new icons: edit and export to keep "edit" and "export" visible and more uniform/extendable (can have more options). What do you think of this solution? Or do you think I should consolidate edit and export into "actions"? I grouped it in that way originally (or at least in the source, and visually), but I thought as a section itself it might have been too vague/doesn't really convey what "actions" are, until you click on it--so I opted to separate them so it's more apparent what the viewer can do. Let me know what your opinion is on this. - "Main" naming of the section is kind of confusing since "Main" is also > the name of a space in XWiki. If you removed the things mentioned above > you > can call it "Navigation" or something else, since it will contain table of > content, quicklinks, recent, etc. (mostly panels content) Makes sense. Thanks Just for your information, I don't know if you've read my proposal about > Collaborative Editing > > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/CollaborativeEditi… Thank you, seems really interesting. Beautiful graphs/statistics are super engaging. The collaborative tool I think is definitely really useful as well--I know it is a big sticking point for gdocs. Although the topic is different from your project, you can see some mockups > of another possible skin for XWiki. Is build with Twitter Bootstrap just > like Jerome's Lyrebird. Could be useful to have as inspiration or at least > to know about it. yes, it has been very useful to learn more as I integrate. First, great work overall. I think we are on the right track to make > something great out of this summer of code! Thank you. Definitely great support from you and the community. Learning a lot in the process. I think the next step is to start integrating with XWiki. We'll probably > hit more real world problems doing this :) I agree, I have started doing this, but am already running into a few problems. The last couple days I was cleaning up the code/optimizing to prepare for this. I now tested the codes in firefox/chrome/opera/safari & android/wp/ blackberry(minor issue with it's inability to rotate text--thinking of a solution). The code also now implements html5 elements. You can create a repo on your github account or we can create one in > xwiki-contrib if you prefer. What you be great would be to have a pom.xml > for it, you can take inspiration from the one I've made for Lyrebird for > example. I can help you with that if you need. Here is the github for the implementation: https://github.com/jssolichin/xo5 I have a question about this. I know pom.xml is used to build for maven, but is it necessary for a skin/what other purpose does it serve? At the moment I'm just dropping files into: "webapps\xwiki\skins\"--since when I build Lyrebird, i get the xar (which i uploaded through the admin--something I don't see is needed yet since they are just configuration files for the skin right?) and the zip (which i unzip into the skins directory). Sorry If I am missing something big. Also, here is my understanding of xwiki skin, correct me if I'm wrong ( http://platform.xwiki.org/xwiki/bin/view/DevGuide/Skins seems to mostly be overriding than an overall change--is there another guide I am not seeing?). XWIKI sees the skin folder and looks for .vm files. If a .vm is not found in that skin's folder, it goes to the .vm in the templates folder. .vm calls on other .VMs for parts. My questions are: *Is there a way to see which .vm something is coming from? like a developer view or sth, that shows where all the parts are coming from (presently I am just ctrl+f the folder for a markup nearby to the things I want to change/add--doesn't seem to be very efficient.) *Is there a list of default .VMs that xwiki looks for? (this maybe over simplifying it, but like in wordpress, a skin has a core of index.php(main landing page), single.php(each post), archive.php (search/archive) etc. and they call on arbritary .php parts (eg. header.php, footer.php etc.)). Or am I thinking about this the wrong way? *I know this sounds a little bit vague, but what was your workflow in implementing bootstrap? I have to admit, I'm a little bit lost, and I'm afraid that I am going about this all the wrong way. *A more specific question, which you may not have time to answer, but presently I am stuck in coding the global breadcrumb section. So the way I am seeing it, it is being pulled from the menuview.vm, which calls upon macros.vm. I am changing the macros.vm (say to remove the down triangle ▼ ), but it seems that it is not changing the skin at all. Am I doing this incorrectly?/is there a cache not clearing? (this is in the repo xo5) On Code Style (http://dev.xwiki.org/xwiki/bin/view/Community/CodeStyle): *If I click the velocity, it leads me to an editor and not an article? Couple of random remarks : > * we need to think how the "search suggest" (search results as you type) > will integrate what if it replaces the main content area (where the article is for that page)? > * you can also start to think about the "edit" mode (say with the WYSIWYG > editor to begin with). Ok! Sorry if this all sounds really basic/there is an article that I am not reading (or I am missing/didn't see). If you could point me in the right direction, that would be sweet. Thank you again for all the patience and support! Best, Jonathan Solichin

12 years, 5 months

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs July 2012