April 2011 - xwiki-devs@xwiki.org

Re: [xwiki-devs] Photo Album Application for GSOC 2011
by Ecaterina Moraru (Valica) 06 Apr '11

06 Apr '11

Hi, On Wed, Apr 6, 2011 at 22:23, shweta agrawal <shweta.9996(a)gmail.com> wrote: > Hi, > > I have identified following task list. > > *File Uploading Part -* > Allow upload of Zip files and Extracting image files from zip archive > (java.util.zip package). > //use storage implementation accordingly - filesystem or database. > //image compression can be done by using java image io api. As Marius > said there is only resizing capability available in xwiki and jpeg with > quality near to 60% are optimum for web display, so compression can be used. > > > *Extracting EXIF information from image files.* (This information can be > stored in a separate db table. I found this > http://www.drewnoakes.com/drewnoakes.com/code/exif/. It's a java metadata > extractor library for jpeg image files. ) > > Tags - allowing *tagging of attachments*. We can have a separate column of > tags in the attachment_content table where different tags can be stored > (separeted via pipeline). WDYT? > Tags can be displayed just for the attachments in the photo application. We can make it general, but we need to see more use cases. Right now in XWiki the only things you can add tags are pages. Tags are represented as objects. > Comments - associating *comments with an attachment*. As I have no idea > how comments are stored so can't say anything about it right now. > Just like tags, comments are stored as objects to pages. > > Designing and Implementing *Browsing Interface and Album/Photo > manipulation interface* > Browsing Interface - interface that allows users to browse albums easily > thumbnail view and slide show > browse based on some metadata info like author or location > Album manipulation interface > Add Photos > Delete Photos > Managing manipulation rights for the album > Editing basic info about Album > Photo Manipulation Interface > Using canvas element - manipulate rotation, opacity, cropping, adjusting > gamma, contrast, brightness etc > Editing basic info about Photo > > Currently I am working on gsoc proposal and basic drafts of album browsing > interface. > Is this task list ok? > The list is ok. Go ahead and complete your proposal. Thanks, Caty > Further, I am thinking that I should start with Browsing Interface, then > after that file uploading part and EXIF information extraction will be > implemented. What do you say? (I need it for describing project plan and > timeline in gsoc proposal). > > Looking for your feedback. > > Thanks > Shweta Agrawal > > On Mon, Apr 4, 2011 at 8:05 PM, Ecaterina Moraru (Valica) < > valicac(a)gmail.com> wrote: > > Hi, >> >> >> On Sat, Apr 2, 2011 at 14:03, shweta agrawal <shweta.9996(a)gmail.com>wrote: >> >> Hi, >>> >>> >>> I have checked out the HTML 5 specifications for geo-location api, file >>> uploading api and canvas container. >>> >>> At present, all the attachments are stored in database irrespective of >>> their nature (the old photo album also uses db to store images). I browsed >>> to find out which is better for storing image files - database or file >>> system and found that most of the posts favored filesystem (in case of large >>> number of images). I need your suggestion regarding which one is better in >>> xwiki's context. In case of using filesystem for storing image files, >>> migration of older version photo albums will be complicated as image files >>> will need to be imported from database to file system. >>> >> Right now from what I know attachments are stored in the database. Caleb >> is working on a new storage that will use the filesystem. So IMO you don't >> have to worry about this aspect and also it will not be very relevant for >> this project (you will only have to use the storage, not implement it). See >> http://markmail.org/thread/pl7v4sew2ujksrvv >> >> >>> Secondly, most of the online photo album application (flickr, picasa web >>> album, facebook) uses image compression for rendering images fastly on >>> slower networks, so do we also intend to use some compression algorithm and >>> optimize the image files for display on web. (xwiki can have something of >>> this sort that is if image size is more than some threshold value (say 1 Mb >>> or 512 kb) then it can be stored as a compressed image). I haven't checked >>> out which algorithms are used and does there exist any library or API for >>> image compression, so can't say how much time it will take to implement. >>> >>> I think we already have some image compression on the server side. Marius >> can give more information about this. See >> http://markmail.org/thread/kbazwdlgmrlsllcv >> >> >>> what about sharing photo album only with a specific group not all users >>> and also having manipulating rights to some users only (unlike the old photo >>> album application, any registered user can add or delete photos created by >>> some other user)? >>> >>> >>> This won't be a problem either. If the application is located at space >> level and let's say albums are identified at page level, then you can easily >> play with the rights system and give permissions just to a group or user, >> etc. See >> http://platform.xwiki.org/xwiki/bin/view/Features/RightsManagement >> >> Thanks, >> Caty >> >> >>> Thanks >>> Shweta Agrawal >>> >>> >>> On Tue, Mar 29, 2011 at 2:35 AM, Ecaterina Moraru (Valica) < >>> valicac(a)gmail.com> wrote: >>> >>> >>>> >>>> On Mon, Mar 28, 2011 at 16:38, shweta agrawal <shweta.9996(a)gmail.com>wrote: >>>> >>>> Hi, >>>>> >>>>> I am Shweta Agrawal, final year computer science student at IIT >>>>> Roorkee, >>>>> India. I want to apply for GSoC this year and am interested in working >>>>> on >>>>> Photo Album Application. I have four year experience in web >>>>> development and >>>>> have good understanding of HTML, CSS, Php, python and Javascript. I >>>>> have >>>>> worked on creating user interfaces for a couple of websites and >>>>> developed >>>>> applications like online music player (similar to grooveshark), online >>>>> notice board etc for my Institute's intranet. >>>>> >>>>> As far as I understand the project, it's aimed at developing an >>>>> application >>>>> where users can >>>>> >>>>> - upload the photos (one by one or zip files or folders) with >>>>> information like date, caption, location etc.- this info can be >>>>> extracted by >>>>> reading exif information. *additional* - multiple file selection and >>>>> upload, drag and drop functionality (supported by HTML 5 compliant >>>>> browsers). ** *doubt* that do we intend to create a default album for >>>>> all >>>>> the images uploaded/attached by user on any of the pages i.e. not >>>>> only the >>>>> images that are uploaded for some album. It will provide user an easy >>>>> way to >>>>> manipulate and browse through all uploaded image files. >>>>> >>>>> the intent is to have albums. This means the user specifies the desired >>>> photos he wants to add to his album. >>>> About your idea: to have an album with all the images uploaded by user: >>>> this is already accessible if you go to Main/AllDocs?view=attachments and >>>> filter the user. >>>> >>>> >>>>> - create albums and add information like title, caption, description >>>>> and >>>>> location. *doubt* - will there be any limit on maximum number of >>>>> photographs in an album? >>>>> >>>>> we don't have any limit on the number of attachments we add to a page, >>>> so we shouldn't have a limit here either. >>>> >>>> >>>>> - browse through the uploaded photographs (available in browsers not >>>>> having javascript - It can be done using css3). >>>>> >>>> we recently have something like >>>> http://extensions.xwiki.org/xwiki/bin/view/Extension/Gallery+Macro >>>> and >>>> >>>> http://extensions.xwiki.org/xwiki/bin/view/Extension/Attachment+Selector+Ma… >>>> to give you some example of extensions that handle attachment viewers. >>>> >>>> >>>>> - view as thumbnails and slideshow (with adjustable timer and with >>>>> manual browsing). >>>>> >>>>> >>>>> - migration tool from the old version photo albums. *doubt* - what >>>>> does >>>>> old version photo albums refer to? >>>>> >>>> This is the very old Photo album application that we want to replace. >>>> >>>> http://extensions.xwiki.org/xwiki/bin/view/Extension/Photo+Album+Application >>>> >>>> >>>>> - ability to tag and associate comments with attachments. *doubt* - >>>>> does >>>>> attachments here refers to image files only or any type of files. >>>>> >>>> for the purpose of this project refers to images, but this should be >>>> extensible so we could comment on any type of files. >>>> >>>> >>>>> I have browsed through the code of older photo album application. I >>>>> need >>>>> guidance that is how should I start working on this application? I am >>>>> thinking about starting with uploading part. >>>>> >>>>> Learn a bit XWiki structure and the way applications and extensions are >>>> done, integrated and reused. >>>> You can find lots of applications at >>>> http://extensions.xwiki.org/xwiki/bin/view/Main/ >>>> You can play with them, see also the source code, etc. >>>> >>>> The specifications for this project are very oriented towards the HTML5 >>>> standard so you should check that out too. >>>> >>>> Thanks, >>>> Caty >>>> >>>> >>>>> Looking forward to your feedback. >>>>> >>>>> Regards >>>>> >>>>> Shweta Agrawal >>>>> B.Tech IV YR CSE >>>>> IIT Roorkee >>>>> _______________________________________________ >>>>> devs mailing list >>>>> devs(a)xwiki.org >>>>> http://lists.xwiki.org/mailman/listinfo/devs >>>>> >>>> >>>> >>> >> > >

1 0

[xwiki-devs] Photo Album Application for GSOC 2011
by shweta agrawal 06 Apr '11

06 Apr '11

Hi, I have identified following task list. *File Uploading Part -* Allow upload of Zip files and Extracting image files from zip archive (java.util.zip package). //use storage implementation accordingly - filesystem or database. //image compression can be done by using java image io api. As Marius said there is only resizing capability available in xwiki and jpeg with quality near to 60% are optimum for web display, so compression can be used. *Extracting EXIF information from image files.* (This information can be stored in a separate db table. I found this http://www.drewnoakes.com/drewnoakes.com/code/exif/. It's a java metadata extractor library for jpeg image files. ) Tags - allowing *tagging of attachments*. We can have a separate column of tags in the attachment_content table where different tags can be stored (separeted via pipeline). WDYT? Comments - associating *comments with an attachment*. As I have no idea how comments are stored so can't say anything about it right now. Designing and Implementing *Browsing Interface and Album/Photo manipulation interface* Browsing Interface - interface that allows users to browse albums easily thumbnail view and slide show browse based on some metadata info like author or location Album manipulation interface Add Photos Delete Photos Managing manipulation rights for the album Editing basic info about Album Photo Manipulation Interface Using canvas element - manipulate rotation, opacity, cropping, adjusting gamma, contrast, brightness etc Editing basic info about Photo Currently I am working on gsoc proposal and basic drafts of album browsing interface. Is this task list ok? Further, I am thinking that I should start with Browsing Interface, then after that file uploading part and EXIF information extraction will be implemented. What do you say? (I need it for describing project plan and timeline in gsoc proposal). Looking for your feedback. Thanks Shweta Agrawal On Mon, Apr 4, 2011 at 8:05 PM, Ecaterina Moraru (Valica) <valicac(a)gmail.com > wrote: Hi, > > > On Sat, Apr 2, 2011 at 14:03, shweta agrawal <shweta.9996(a)gmail.com>wrote: > > Hi, >> >> >> I have checked out the HTML 5 specifications for geo-location api, file >> uploading api and canvas container. >> >> At present, all the attachments are stored in database irrespective of >> their nature (the old photo album also uses db to store images). I browsed >> to find out which is better for storing image files - database or file >> system and found that most of the posts favored filesystem (in case of large >> number of images). I need your suggestion regarding which one is better in >> xwiki's context. In case of using filesystem for storing image files, >> migration of older version photo albums will be complicated as image files >> will need to be imported from database to file system. >> > Right now from what I know attachments are stored in the database. Caleb is > working on a new storage that will use the filesystem. So IMO you don't have > to worry about this aspect and also it will not be very relevant for this > project (you will only have to use the storage, not implement it). See > http://markmail.org/thread/pl7v4sew2ujksrvv > > >> Secondly, most of the online photo album application (flickr, picasa web >> album, facebook) uses image compression for rendering images fastly on >> slower networks, so do we also intend to use some compression algorithm and >> optimize the image files for display on web. (xwiki can have something of >> this sort that is if image size is more than some threshold value (say 1 Mb >> or 512 kb) then it can be stored as a compressed image). I haven't checked >> out which algorithms are used and does there exist any library or API for >> image compression, so can't say how much time it will take to implement. >> >> I think we already have some image compression on the server side. Marius > can give more information about this. See > http://markmail.org/thread/kbazwdlgmrlsllcv > > >> what about sharing photo album only with a specific group not all users >> and also having manipulating rights to some users only (unlike the old photo >> album application, any registered user can add or delete photos created by >> some other user)? >> >> >> This won't be a problem either. If the application is located at space > level and let's say albums are identified at page level, then you can easily > play with the rights system and give permissions just to a group or user, > etc. See > http://platform.xwiki.org/xwiki/bin/view/Features/RightsManagement > > Thanks, > Caty > > >> Thanks >> Shweta Agrawal >> >> >> On Tue, Mar 29, 2011 at 2:35 AM, Ecaterina Moraru (Valica) < >> valicac(a)gmail.com> wrote: >> >> >>> >>> On Mon, Mar 28, 2011 at 16:38, shweta agrawal <shweta.9996(a)gmail.com>wrote: >>> >>> Hi, >>>> >>>> I am Shweta Agrawal, final year computer science student at IIT Roorkee, >>>> India. I want to apply for GSoC this year and am interested in working >>>> on >>>> Photo Album Application. I have four year experience in web development >>>> and >>>> have good understanding of HTML, CSS, Php, python and Javascript. I have >>>> worked on creating user interfaces for a couple of websites and >>>> developed >>>> applications like online music player (similar to grooveshark), online >>>> notice board etc for my Institute's intranet. >>>> >>>> As far as I understand the project, it's aimed at developing an >>>> application >>>> where users can >>>> >>>> - upload the photos (one by one or zip files or folders) with >>>> information like date, caption, location etc.- this info can be >>>> extracted by >>>> reading exif information. *additional* - multiple file selection and >>>> upload, drag and drop functionality (supported by HTML 5 compliant >>>> browsers). ** *doubt* that do we intend to create a default album for >>>> all >>>> the images uploaded/attached by user on any of the pages i.e. not only >>>> the >>>> images that are uploaded for some album. It will provide user an easy >>>> way to >>>> manipulate and browse through all uploaded image files. >>>> >>>> the intent is to have albums. This means the user specifies the desired >>> photos he wants to add to his album. >>> About your idea: to have an album with all the images uploaded by user: >>> this is already accessible if you go to Main/AllDocs?view=attachments and >>> filter the user. >>> >>> >>>> - create albums and add information like title, caption, description >>>> and >>>> location. *doubt* - will there be any limit on maximum number of >>>> photographs in an album? >>>> >>>> we don't have any limit on the number of attachments we add to a page, >>> so we shouldn't have a limit here either. >>> >>> >>>> - browse through the uploaded photographs (available in browsers not >>>> having javascript - It can be done using css3). >>>> >>> we recently have something like >>> http://extensions.xwiki.org/xwiki/bin/view/Extension/Gallery+Macro >>> and >>> >>> http://extensions.xwiki.org/xwiki/bin/view/Extension/Attachment+Selector+Ma… >>> to give you some example of extensions that handle attachment viewers. >>> >>> >>>> - view as thumbnails and slideshow (with adjustable timer and with >>>> manual browsing). >>>> >>>> >>>> - migration tool from the old version photo albums. *doubt* - what >>>> does >>>> old version photo albums refer to? >>>> >>> This is the very old Photo album application that we want to replace. >>> >>> http://extensions.xwiki.org/xwiki/bin/view/Extension/Photo+Album+Application >>> >>> >>>> - ability to tag and associate comments with attachments. *doubt* - >>>> does >>>> attachments here refers to image files only or any type of files. >>>> >>> for the purpose of this project refers to images, but this should be >>> extensible so we could comment on any type of files. >>> >>> >>>> I have browsed through the code of older photo album application. I >>>> need >>>> guidance that is how should I start working on this application? I am >>>> thinking about starting with uploading part. >>>> >>>> Learn a bit XWiki structure and the way applications and extensions are >>> done, integrated and reused. >>> You can find lots of applications at >>> http://extensions.xwiki.org/xwiki/bin/view/Main/ >>> You can play with them, see also the source code, etc. >>> >>> The specifications for this project are very oriented towards the HTML5 >>> standard so you should check that out too. >>> >>> Thanks, >>> Caty >>> >>> >>>> Looking forward to your feedback. >>>> >>>> Regards >>>> >>>> Shweta Agrawal >>>> B.Tech IV YR CSE >>>> IIT Roorkee >>>> _______________________________________________ >>>> devs mailing list >>>> devs(a)xwiki.org >>>> http://lists.xwiki.org/mailman/listinfo/devs >>>> >>> >>> >> >

1 0

[xwiki-devs] [VOTE] Directory/Git Reorganization re platform vs extensions
by Vincent Massol 06 Apr '11

06 Apr '11

Hi, After brainstorming with Thomas, Sergiu and Fabio we came to the following idea: Proposal ======= * Don't have top level extension git repositories and instead put all extensions/modules in the top level platform repository * This means releasing all modules/extensions under the *same* version (the platform version) ^^^^^^^^ This is the important part! Pros ==== * Much simpler release process * Much simpler JIRA organization (1 project instead of 50 or so) * Much simpler for the user: simpler to log a new issue in jira + they'll know what version of a module they're using vs having to guess that XE 3.0 uses the Lucene plugin v 1.45) and for contributors Directory org ========== platform/ |_ modules/ |_ xwiki-platform-search/ |_ xwiki-platform-search-lucene/ |_ xwiki-platform-search-application/ |_ xwiki-platform-url/ |_ xwiki-platform-skin-colibri/ |_ xwiki-platform-wysiwyg/ |_ ... |_ tools/ |_ distribution/ Details: * Modules contains a flat list of directories, each directory representing a "feature". Everything corresponding to a feature is under that feature's directory, independently of the underlying technologies used (be it plugins, components, xar, etc) * Maven modules previously located in platform/web are moved in platform/modules. Except platform/web/standard which goes in platform/distribution. wysiwyg modules go in xwiki-platform-wysiwyg/ (we need to decide if gwt-dom and gwt-user modules go in there too or if we want to have a xwiki-platform-gwt module - Marius?) Migration details ============= * Change the current org in git * Move several jira projects to retired * Modify platform jira project to have one jira component per feature (ie per platform/modules module). Note that since the old xwiki-core contains lots of stuff I propose to have one jira components for each "feature" it contains. For example for anything related to the model it would go in the "model" jira component. For things going in the user management it would go in a "user and group" component, etc. I'll make a proposal for the full list of jira components later on if this vote is passed. * Future: decide if we keep extensions.xwiki.org and if so what we put in there (maybe just user extensions and move platform features in platform.xwiki.org) Here's my +1 (meaning I'll help perform this move) Thanks -Vincent

8 29

Re: [xwiki-devs] [proposal] Move away from XWQL, it is invalid JPQL (JPA) thus it is it's own (undefined) standard.
by Ludovic Dubost 06 Apr '11

06 Apr '11

Le 04/04/11 19:58, Caleb James DeLisle a écrit : > > On 04/04/2011 12:47 PM, Ludovic Dubost wrote: >> Le 04/04/11 16:37, Caleb James DeLisle a écrit : >>> On 04/04/2011 10:01 AM, Sergiu Dumitriu wrote: >>>> On 04/02/2011 02:22 PM, Caleb James DeLisle wrote: >>>>> After searching through documentation on JPQL (JPA's query language) I was unable to find any >>>>> example of the "doc.object(XWiki.XWikiUsers)" construct. This means XWQL is it's own standard and >>>>> there is no authoritative reference on it. What makes an implementation compliant? I have found >>>>> that >>>>> most HQL queries can be executed as XWQL queries with little or no modification so if compliance is >>>>> defined as being "just like the reference implementation" then nearly all HQL must be >>>>> implemented in >>>>> order to be compliant. >>>> The goal of XWQL was to not be bound to a certain query language, but to >>>> be able to map it to as many QLs as possible, be they SQL-related, like >>>> HQL or JPQL, or other types of queries, like QBE, XPath, SPARQL. So, it >>>> wasn't meant from the start to be compatible with any standard. >>> The problem now is we don't have any specification to tell us what is valid and what is not. >>> Is this a valid XWQL query? >>> >>> $services.query.xwql("from BaseObject as obj where doc.fullName = obj.name and obj.className = >>> 'XWiki.XWikiUsers'").execute() >>> >>> Run it and you might be surprised. >>> Based on that, we have no way of ensuring that a query which works now will work in a new XWQL >>> implementation which defeats the purpose of abstracting the user away from HQL. >>> >>>> Now, I'm not sure if the right thing to do is to move to a standard >>>> query language, or to stick with our own. >>> If we're going to define our own query language (I think there are enough already) there are certain >>> things we have to do such as writing a specification. I frankly find this thing embarrassing. >>> >>>> - Is there any tool that allows mapping a JPQL or JDOQL query into other >>>> query languages? >>> http://www.datanucleus.org/products/accessplatform_3_0/datastores.html >>> These folks are mapping JDOQL and JPQL into a whole bunch of different types of storage. >>> >>>> - Is there a way to parse a query into a tree/AST? >>>> - Other than the fact that it's a non-standard language (and all the >>>> consequences of this, like no support from tools and libraries), are >>>> there any downsides to having our own query language? >>> This particular one has 2 downsides: >>> 1. There is no official specification. >>> 2. HQL can be run as shown above. >>> >>> The major downside of implementing one correctly is that it is massively complicated. >>> >>> Caleb >>> >>>> The benefit of XWQL was that it allowed to write domain specific >>>> queries, which are shorter and easier to understand (at least in theory). >>>> >>>>> Looking at the specifications I have rewritten the example query in compliant JPQL and JDOQL. >>>>> I wrote these so that they would work if all objects were custom mapped which is similar to the >>>>> appearance XWQL gives. >>>>> >>>>> XWQL: >>>>> (SELECT doc.fullName FROM XWikiDocument as doc) where doc.author = 'XWiki.LudovicDubost' and >>>>> doc.object(XWiki.XWikiUsers).email like '%xwiki.com' >>>>> >>>>> JPQL: >>>>> SELECT doc.fullName FROM XWikiDocument as doc, IN(doc.xObjects) obj WHERE obj.className = >>>>> 'XWiki.XWikiUsers' and obj.email LIKE '%xwiki.com' >>>>> >>>>> JDOQL: >>>>> SELECT this.fullName FROM XWikiDocument WHERE this.xObjects.containsValue(obj)&& obj.className == >>>>> "XWiki.XWikiUsers"&& obj.email.startsWith("xwiki.com") >>>>> >> The key objective of XWQL is to abstract from the XWiki point of view and make it as simple as >> possible to write queries. >> If I take this (valid) query in XWQL: >> >> from doc.object(Blog.BlogPostClass) as blogarticle where 'Blog.Blogging' member of blogarticle.category > I'm not 100% sure on this since I don't have a JDOQL database here but I think this will work: > (assuming we still start the query with "SELECT doc.fullName from XWikiDocument as doc where ") > > doc.xObjects.containsValue(article)&& article.className == "Blog.Blogging"&& > article.category.contains("Blog.Blogging") > > It is 18 letters longer, does 18 letters justify throwing out a perfectly good (and well thought > out) specification and countless pages of tutorials and reference material? Well we REALLY need to make this simple for users. The main complaint in HQL is the additional useless joins. Also we want as natural ways to write things. Users are used to SQL. In your example there is: doc.xObjects.containsValue(article)&& article.className == "Blog.Blogging" instead of from doc.object(Blog.BlogPostClass) as blogarticle Franckly the "doc.xObjects.containsValue(article)" sounds very weird. This would yet again be something users won't be able to master. We want to be as close to: "from Blog.BlogPostClass as article where article.title like '%xxx%'" I think XWQL is very close from that. Ludovic >> It seems to me that it would be more complex in JPQL or JDOQL, which is not very cool. >> I'm -1 from any new query language that would end up being more complex. >> >> If I take your 2 downsides: >> >> 1/ Official spec >> >> Well we should write one. It seems normal to me that a new query language has no spec. >> But this does not mean that we don't need a language. > Usually things go the other way, if you write an implementation then define the spec from it, how do > you know a bug from a feature? > >> Unless we can find a standard language that is as easy to use as XWQL, let's stick to XWQL. >> If we need to improve XWQL let's improve it. > How much effort are willing to invest? A query language is like a small programming language. It is > not something to be taken lightly. > >> 2/ HQL can be run >> >> That's an implementation issue. XWQL's objective is to write and run after translations to whatever >> is needed by the backend. > Since we are lacking any specification, the implementation is all we have. To write a spec we will > have to ask "is that a bug or a feature?" with every possible construct. > >> It is VERY important to have a simple query language. It took a long time to learn how to run joins >> in HQL which are not needed from a pure "functionnal" standpoint. > Total +1 here, nobody should ever have to say JOIN in a query. Fortunately JOIN is not even a > keyword in JDOQL :) > > Caleb > >> BTW I had fixed XWiki's query generator which now generates XWQL. It needs XWiki 2.7.1+ >> >> Example here: >> >> http://www.ludovic.org/xwiki/bin/view/Test/Query?query=1&classname=Blog.Blo… >> >> >> I will document it and publish it on extensions.xwiki.org >> >> Ludovic >> >> >>>>> I understood that XWQL was simply a translation scheme which made it appear that we were using JPQL >>>>> with the schema we wanted when really we were using HQL with the schema we had. Given that it is >>>>> not >>>>> compliant JPQL that is not the case. >>>>> >>>>> I think when we update the schema, we should cut our losses with this thing and move to something >>>>> which has a reference document and is more widely used. >>>>> >>>>> WDYT? >>>>> >>>>> Caleb >>>>> >>>>> >>>>> >>>>> The JPQL specification (originally called EJBQL): >>>>> ejb-3_0-fr-spec-ejbcore.pdf chapter 9. >>>>> http://jcp.org/aboutJava/communityprocess/final/jsr220/ >>>>> >>>>> The JDOQL specification: >>>>> jdo-3_0-mrel3-spec.pdf chapter 26. >>>>> http://db.apache.org/jdo/specifications.html >>>>> >>>>> Easy to read, example rich descriptions: >>>>> http://www.datanucleus.org/products/accessplatform_3_0/jpa/jpql.html >>>>> http://www.datanucleus.org/products/accessplatform_3_0/jdo/jdoql.html >>> _______________________________________________ >>> devs mailing list >>> devs(a)xwiki.org >>> http://lists.xwiki.org/mailman/listinfo/devs >>> >> > -- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

2 1

[xwiki-devs] Creating JIRA project for xwiki.org
by Vincent Massol 06 Apr '11

06 Apr '11

Just a FYI that I'm creating a JIRA project for documentation on xwiki.org (instead of having this as a jira component in Platform). Thanks -Vincent

2 1

[xwiki-devs] A Few More Ideas on Auto Complete
by Hasitha Abeykoon 06 Apr '11

06 Apr '11

Hi Marius Dumitru , As you have instructed I looked into "Auto Completion" mail threads. Sorry I was busy with exams past few days, thus i could not keep the touch. - I went through Aparche Lucene in oder to figure out the capability of using it in the suggested project. It does not seems to give everything which is needed to implement the auto completion (specially the image facilities.) Please correct me if i am wrong on this. - Can we use JQUERY in oder to do some client side processing? Caching the Macros and pictures which have been recently used will be stored in the browsers cache until the users log out. - I also looked into how Microsoft word does autocompletion. - Please direct me the on current technologies which can be relevant. Thanks -- *Hasitha Abeykoon,* *Department of Computer Science & Engineering,* *University of Moratuwa. * * * *Skype: foreverhasitha*

2 2

[xwiki-devs] [proposal] Move away from XWQL, it is invalid JPQL (JPA) thus it is it's own (undefined) standard.
by Caleb James DeLisle 06 Apr '11

06 Apr '11

After searching through documentation on JPQL (JPA's query language) I was unable to find any example of the "doc.object(XWiki.XWikiUsers)" construct. This means XWQL is it's own standard and there is no authoritative reference on it. What makes an implementation compliant? I have found that most HQL queries can be executed as XWQL queries with little or no modification so if compliance is defined as being "just like the reference implementation" then nearly all HQL must be implemented in order to be compliant. Looking at the specifications I have rewritten the example query in compliant JPQL and JDOQL. I wrote these so that they would work if all objects were custom mapped which is similar to the appearance XWQL gives. XWQL: (SELECT doc.fullName FROM XWikiDocument as doc) where doc.author = 'XWiki.LudovicDubost' and doc.object(XWiki.XWikiUsers).email like '%xwiki.com' JPQL: SELECT doc.fullName FROM XWikiDocument as doc, IN(doc.xObjects) obj WHERE obj.className = 'XWiki.XWikiUsers' and obj.email LIKE '%xwiki.com' JDOQL: SELECT this.fullName FROM XWikiDocument WHERE this.xObjects.containsValue(obj) && obj.className == "XWiki.XWikiUsers" && obj.email.startsWith("xwiki.com") I understood that XWQL was simply a translation scheme which made it appear that we were using JPQL with the schema we wanted when really we were using HQL with the schema we had. Given that it is not compliant JPQL that is not the case. I think when we update the schema, we should cut our losses with this thing and move to something which has a reference document and is more widely used. WDYT? Caleb The JPQL specification (originally called EJBQL): ejb-3_0-fr-spec-ejbcore.pdf chapter 9. http://jcp.org/aboutJava/communityprocess/final/jsr220/ The JDOQL specification: jdo-3_0-mrel3-spec.pdf chapter 26. http://db.apache.org/jdo/specifications.html Easy to read, example rich descriptions: http://www.datanucleus.org/products/accessplatform_3_0/jpa/jpql.html http://www.datanucleus.org/products/accessplatform_3_0/jdo/jdoql.html

6 12

[xwiki-devs] Git Migration - What's the plan?
by Vincent Massol 05 Apr '11

05 Apr '11

Hi devs, I see Sergiu has started the git migration, cool. However could we list the different actions to be done and when they'll be done by whom. I'll start listing some questions: * Can we continue commit in svn? Has it been put readonly? If not, shouldn't this be done first step? * Can we commit in the git repos created on github right now? If not when? * Are we going to continue having the git repos synced with the svn repo and if so for how long? * I've done a commit on git earlier today but didn't see any email notifications on the notifications list? Can this be set up quickly so that we can see what's happening? * I'm surrounded by git users for the week end and they're telling me there are several ways to use git (one master repo, 2 repos, etc) and that we need to define best practices of how we want to use git since there are lots of ways to use it. Any idea about this? Ok enough question to get started. Thanks -Vincent

5 10

[xwiki-devs] [GSoC 2011] Self Introduction and Interested Project
by Jun Han 05 Apr '11

05 Apr '11

Hi, Everyone, I am going to apply for student developer in GSoC 2011 and am interested in one of proposed XWiki projects, XEclipse "RESTification". Currently I am a fourth year Ph.D. student in the department of Computer Science, University of Georgia, USA. My research focuses on Simulation/Modelling and Web services, and applies them to facilitate bioinformatics research. My strengths are the following: (1). 6-year of Java programming experience including both desktop and web development and able to perform full lifecyle software development. (2). developed a SOAP Web service management system using Eclipse RCP and SWT (3). developed REST-ful Web services and integrated SOAP Web services from other collaborators (in German and Japan) to implement integrated scientific workflow following Web 2.0 standards After reading through the descriptions of proposed projects, XEclipse "RESTification" is of great interest to me. This project involves communication via SOAP and REST-ful Web services and is developed in Eclipse SWT platform, therefore, I might be a potential match for this project based on the skill set. I have several questions regarding the requirement: (1) what is target development platform? The current XEclipse requires Eclipse Ganymede 3.4 and the most recent release is Eclipse 3.6 and 3.7. Is there any plan to support them? (2) What is the current status of XWiki communication layer? From what I understand, SOAP + XML play a main role in the current system. Now XWiki is turning to REST eventually. I read some discussions on Mar 11 2011 about REST API in dev mail list, which mentioned that REST API is not there yet. Does this mean that the whole REST communication layer is not available yet? (3) What extent of RESTification we are going to achieve for XEclipse? This is closely related to question (2). If REST API is available, the XEclipse RESTification will only need to construct the REST-ful request (i.e., @GET /rest/{space}/{page}) and parse result from server. If not, more work might be involved. Best regards Jun Han -- Jun Han Computer Science Department, the University of Georgia http://sites.google.com/site/junhan37/

4 8

[xwiki-devs] Photo Album Application for GSOC 2011
by shweta agrawal 04 Apr '11

04 Apr '11

Hi, I am Shweta Agrawal, final year computer science student at IIT Roorkee, India. I want to apply for GSoC this year and am interested in working on Photo Album Application. I have four year experience in web development and have good understanding of HTML, CSS, Php, python and Javascript. I have worked on creating user interfaces for a couple of websites and developed applications like online music player (similar to grooveshark), online notice board etc for my Institute's intranet. As far as I understand the project, it's aimed at developing an application where users can - upload the photos (one by one or zip files or folders) with information like date, caption, location etc.- this info can be extracted by reading exif information. *additional* - multiple file selection and upload, drag and drop functionality (supported by HTML 5 compliant browsers). ** *doubt* that do we intend to create a default album for all the images uploaded/attached by user on any of the pages i.e. not only the images that are uploaded for some album. It will provide user an easy way to manipulate and browse through all uploaded image files. - create albums and add information like title, caption, description and location. *doubt* - will there be any limit on maximum number of photographs in an album? - browse through the uploaded photographs (available in browsers not having javascript - It can be done using css3). - view as thumbnails and slideshow (with adjustable timer and with manual browsing). - migration tool from the old version photo albums. *doubt* - what does old version photo albums refer to? - ability to tag and associate comments with attachments. *doubt* - does attachments here refers to image files only or any type of files. I have browsed through the code of older photo album application. I need guidance that is how should I start working on this application? I am thinking about starting with uploading part. Looking forward to your feedback. Regards Shweta Agrawal B.Tech IV YR CSE IIT Roorkee

3 4