- xwiki-devs@xwiki.org - lists.xwiki.org

Re: [xwiki-devs] Access password of current user

by David Delbecq

Indeed, i forgot that in http/basic auth, user/pass are provided by browser on each and every request made to server. This solves my problem on finding the user / pass and i don't have to keep it in memory. Since i can use container based security + jboss basic auth, i suppose this solves my issue without requiring complex trust services. Will give it some tries. Thank you. ----- Mail original ----- De: "Jerome Velociter" <jerome(a)winesquare.net> À: "XWiki Developers" <devs(a)xwiki.org> Envoyé: Mercredi 20 Juin 2012 10:33:58 Objet: Re: [xwiki-devs] Access password of current user On Wed, Jun 20, 2012 at 9:54 AM, David Delbecq <david.delbecq(a)meteo.be>wrote: > > Hello all, > > if someone has access to restricted xwiki area (escalation or any other > way), this someone could just create a javascript wiki page using > skinextension, that will grab password from login form and send it anywhere > in the wiki for later retrieval. So i don't feel like i create any security > hole there. > If a user has access to the server, he could just feed it with it's own > XwikiAuthService or LDAP server that record password before forwarding to > real ldap server. > For me none of this arguments legitimize storing passwords in clear. > > Our company has no kerberos, ntlm, etc server running, so i can't easily > use such solution. Removing password for authentication on background > service is no option either, as wiki will be a portal to those services, > but some operation still need user to navigate to those services. For > example, a webdav service: listing in xwiki page of a folder content should > be done using xwiki current user's priviledges (xwiki is the http client), > but when user want to retrieve a specific file or want to mount the webdav > service on his workstation, he access the webdav service directly. > > Using "unsecure" password is no option either, all users in the company > are supposed to use same password for all services (ldap central > authentication). > > > > Keep in mind, the only things i have write access to is a few jboss > servers, their configuration, and the webapp running on them. All > applications (except unfortunately xwiki) use container based > authentication. I already replied to say XWiki supports container based authentication throught the AppServerTrusted authenticator. What's missing ? If someone has doc on how to forward credentials from one webapp to another > over http(s), i'll be glad to prefer it If you use container based authentication, I imagine you should be able to copy over the authorization header from the originating request to the one you create in your HTTP client (since I understand you are making HTTP calls to the tiers apps). Jerome > , but the only documentions on jboss/sso i have found so far assume all > request come from browser! Kerberos or similar service, while a good > solution as supported by jboss (but "experimental" in xwiki), afaik, > requires to add additionnal schemas to ldap so tickets can be stored. And i > know from experience that if i request such service installed and > configured on our central server, i am not sure to get them before next > year. > > > I understand your concerns, i do not like the idea of storing password in > memory. But i see no viable solution for now to have our xwiki be a portal > to various services on behalf of it's current user. > > Thank you > David Delbecq > ----- Mail original ----- > > De: "Jerome Velociter" <jerome(a)winesquare.net> > À: "XWiki Developers" <devs(a)xwiki.org> > Envoyé: Mardi 19 Juin 2012 15:16:54 > Objet: Re: [xwiki-devs] Access password of current user > > On Tue, Jun 19, 2012 at 2:58 PM, David Delbecq <david.delbecq(a)meteo.be > >wrote: > > > Hello, > > > > > > unfortunately, we don't have any explicit sso service currently running. > > In the past, we simply asked the container (tomcat) to manage > > authentication of users for all our webapplication and we followed tomcat > > directions on how to share principal for all applications ( > > > http://tomcat.apache.org/tomcat-5.5-doc/config/valve.html#Single_Sign_On_Va… > ). > > This works well when all application use container authentication and the > > only client is the user's web browser. Unfortunately, things will change > as > > we will base our intranet on xwiki instead of having separate spread > > applications the user needs to connect to. This mean the web server (now > > jboss) will be the http client of all other services, and thus realm > based > > sso won't work. For some of those service we use generic technical > account, > > so no problem, we just store the password. But for some other, we must > > transmit the user / password of current xwiki user so xwiki is seen by > this > > service as this user. > > > > And none of those behind the scene applications were ever configured to > > use kerberos or anything alike. Moreover, i would like to avoid the > > nightmare of maintaining such a service when simply forwaring user / pass > > to next service would solve my problems :) > > > > Storing plain-text user password is never a good idea, be it on the > database, filesystem or in memory. > > If you store passwords in the session, some XWiki applications could read > them, someone in your organization with programming access level can access > them, a hacker that escalate to have access to the machine or to > programming rights in the application can read them, etc. > > Jerome > > > > > > > Regards, > > David Delbecq > > > > ----- Mail original ----- > > > > De: "Guillaume Lerouge" <guillaume(a)xwiki.com> > > À: "XWiki Developers" <devs(a)xwiki.org> > > Envoyé: Mardi 19 Juin 2012 14:40:16 > > Objet: Re: [xwiki-devs] Access password of current user > > > > Hi David, > > > > which SSO service dou you use internally? XWiki authenticators already > > exist for CAS, Kerberos and NTLM, maybe you could draw inspiration from > > them. > > > > Guillaume > > > > On Tue, Jun 19, 2012 at 1:54 PM, David Delbecq <david.delbecq(a)meteo.be > > >wrote: > > > > > > > > Hello, > > > > > > I was hoping that somehow, when submitted via the form, password gets > > > recorded until the end of the session. We can't afford, for the sake of > > > user experience, to ask password every time user need to access a > hidden > > > system he is not even supposed to know is separate from the wiki. > That's > > > why we are writing some macro / components so that it's xwiki that > access > > > those system for him. This include various webservices, a documents > > storage > > > and so on. We try to keep a single sign on policy. Of course, i don't > > want > > > user password stored anywhere on disks, but keeping it in user session > > > seems a good trade-of for me. > > > > > > I plan thus to create my onw xwikiauthservice that delegates to ldap > > > service and store this in user session. > > > > > > > > > ----- Mail original ----- > > > > > > De: "Jerome Velociter" <jerome(a)winesquare.net> > > > À: "XWiki Developers" <devs(a)xwiki.org> > > > Envoyé: Mardi 19 Juin 2012 11:53:42 > > > Objet: Re: [xwiki-devs] Access password of current user > > > > > > Hi, > > > > > > Fortunately, you can't. You can only access/verify a hashed version of > > > the password. > > > > > > Note that asking for a password again is not necessarily a bad UX, > > > especially if it is to allow access to a sensitive area/operation. > > > > > > Cheers, > > > Jerome. > > > > > > On Tue, Jun 19, 2012 at 11:39 AM, David Delbecq < > david.delbecq(a)meteo.be> > > > wrote: > > > > > > > > Hello, > > > > > > > > i am writing a component that need a password. Because this password > > > will be the same for current user as the one he used to log-in, it > would > > > make for crappy interface ot ask it again to user. So i need to know > how > > my > > > component or a groovy script can access the username / password of > > current > > > logged-in user. > > > > > > > > Thank you. > > > > > > > > > > > > David Delbecq > > > > > > > > _______________________________________________ > > > > devs mailing list > > > > devs(a)xwiki.org > > > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > > > > > > > -- > > > Jérôme Velociter > > > Winesquare > > > http://www.winesquare.net/ > > > _______________________________________________ > > > devs mailing list > > > devs(a)xwiki.org > > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > _______________________________________________ > > > devs mailing list > > > devs(a)xwiki.org > > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > _______________________________________________ > > devs mailing list > > devs(a)xwiki.org > > http://lists.xwiki.org/mailman/listinfo/devs > > _______________________________________________ > > devs mailing list > > devs(a)xwiki.org > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > -- > Jérôme Velociter > Winesquare > http://www.winesquare.net/ > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > -- Jérôme Velociter Winesquare http://www.winesquare.net/ _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

13 years, 2 months

1
0
0 0

[xwiki-devs] [ANN] XWiki Enterprise and XWiki Enterprise Manager 4.0.1 released

by Thomas Mortagne

The XWiki development team is pleased to announce the release of XWiki Enterprise and XWiki Enterprise Manager 4.0.1. Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download This is a bugfix release for the 4.0 cycle. For more information see the Release notes at: http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise401 Thanks -The XWiki dev team

13 years, 2 months

1
1
0 0

[xwiki-devs] 转发: Chinese garbled problem in office-import

by idealhang

2012-06-20 idealhang 发件人：idealhang 发送时间：2012-06-19 17:55 主题：Chinese garbled problem in office-import 收件人："devs"<devs(a)xwiki.org> 抄送： HI I am using the latest xwiki and I need to use its office-import feature. Hower,I upload some chinese word and excel documents,the problem of chinese garbled comes out. The chinese titles are OK. but the chinese content is garbled . I install the xwiki-enterprise-installer-windows-4.1-rc-1.exe on the cn_windows_server_2008_r2_sp1_vl_build_x64_dvd_617396,and my openoffice is Apache_OpenOffice_incubating_3.4.0_Win_x86_install_zh-CN.exe. What should I do to solve the problem，I need your help. Thank you very much. 2012-06-19 idealhang

13 years, 2 months

2
1
0 0

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

by Jonathan Solichin

Hello friends, Caty, thanks for bringing up those points. My only concert is that the functionality is spread in multiple places. I was thinking of that as well just as i hit send. The export section should definitely be part of the page interest area to consolidate (should have moved that). Originally, I put the page functions under the section navigation (main, comments, attachments etc.) because I wanted to put it under the main section (and thus spliced in between the quicklinks and logo/search (global stuff)) since I thought that its presence is not needed 100% of the time. But now that I think about it, maybe it should be there 100% of the time because of the table of contents. What do you (guys) think? Also you now separated the menus in three parts: upper part, edit menu, > view menu. That's true. The original thought was that the edit (for page) should be on the page since it is a prominent action attached to the content. But maybe, since the meta data/view of the page is being consolidated on the right, I will move it there also. I am thinking that I will put the view/page edit into a subsection of the lighter page area (date modified/created etc.) in the sidebar since they are both current user actions. As for the upper part, I understand what you mean that it'd be nice to know what actions can be done, but I think it's ok that it's on top separated since they are not necessarily page specific action right? they act more on a global level? To resolve this, how about adding a pencil icon to these three things that allow for user action (or maybe even just a color change to differentiate actionable section). What do you think? Another thing is the breadcrumb: what is the difference between 'Page: > Platform Features' and 'Page Editing' ? Where am I now? What is the page's > title? 'Platform Features' of 'Page Editing'? i apologize, that breadcrumb is a bit erronous as a result of mishmashed samples. It should read: wiki: XWIKI Platform >> space: Features >> page: Page Editing. The page title, instead of "Wiki Home," should have been "Page Editing". Also for the mobile version you didn't clearly represented the difference > between the collapse/expanded states of gadgets like 'Welcome' and 'Spaces' > (they can be mistaken with headings). good call, i will add a + - to signify them. As for progress report. It unfortunate for me to have to say that this is harder/taking more time than expected. I am struggling at the moment to create the most efficient way to realize the design. A lot of the fluidity/interaction that I had hoped for seems to require a lot more codes than anticipated--that is: the use of javascript instead of native css/html. Even then there are a lot of conflicting codes that needs to be brought together. The complexity is sort of evident in research. Briefly you can check out fb/g+'s implementation. Facebook's approach utilizes a lot of js, and seems to falter when it is disabled (something i'm really worried about). It rewrites the page often (classes etc.) and writes css inline and so forth. G+ uses an even more interesting approach of using iFrames. It is true that this sidebar should not be as complicated as the ones that I am researching from, but as a result of the complexity of existing sidebars that I wish for our sidebar to be similar to (and thus super hard to reverse engineer and understand), and the relative shortage on this topic, I am having to research/experiment more than I expected. In any regards it is all very exciting, and I am getting to learn more than I expected on this project. This is the prototype that I am currently working on (def some bugs): http://jssolichin.com/xwiki/ There are bugs, but I really wanted to share what I had so far. Some of the things to test that I have been working on is the resizing of the side bar, the scrolling, resizing the browser and so forth. I know it is quite simple, but trying to figure out the correct method was/is a challenge. It's still a long ways to go, but I hope that things will get a lot faster since one of the core features/points of this skin is this sidebar. I know that it is not in the code styles of xwiki/implemented into xwiki yet, I think I might need to change the timeline with this development, to make room for this. Right now I'm trying to focus on quick dev, to see what's possible, and what will need a lot more work. On another side note, I am also still having trouble building xwiki from sources (the other half of my time). Just quickly, what environment are you guys using (in terms of OS/java)? I tried ubuntu, and now mint linux, but am still having some trouble with maven from terminal (following the guide on sona system) (i am able to build with eclipse, but I am not sure how to run it with jetty/hsqldb so I can access it on my browser?) Also, are you guys using oracle or openjdk? Thanks for all the support and help thus far, Jonathan Solichin

13 years, 2 months

2
1
0 0

[xwiki-devs] [VOTE] Add extension id in the MANIFEST.MF in WAR distributions

by Thomas Mortagne

Hi devs, Since I got some veto on http://markmail.org/message/feavtmfokcsaalpo lets cut all that in small peaces. The today's episode is about finding what is the war we are running it at runtime to list it in the core extensions (among other things it allows to check for available updates). Like the JAR packages, a WAR contains pom.xml file, problem is that this pom.xml file is not in a "stable" location (META-INF/<groupId>/<artifactId>/pom.xml) and I can't find any generic way to scan a WAR like Reflection allows to scan jars files from the classpath. So as a last resort solution I propose to include the extension identifier in the METAINF.MF at build time. This will give me the entry point I need to find the pom.xml and gather more detailed informations about the war to put it as core extension. WDYT ? +1 -- Thomas Mortagne

13 years, 2 months

6
11
0 0

[xwiki-devs] DB Migration systems uses System.exit! Remove it

by Vincent Massol

Hi devs, I see that Denis has added the following: if ("1".equals(config.getProperty("xwiki.store.migration.exitAfterEnd", "0"))) { logger.error("Exiting because xwiki.store.migration.exitAfterEnd is set"); System.exit(0); This is really bad IMO since System.exit should never be used in JavaEE/Servlet apps. See also http://nemo.sonarsource.org/drilldown/violations/XWIKI?rids%5B%5D=367322&ru… One problem for example is that this will stop the full Servlet JVM so if XWiki runs in a Servlet container running several other webapps suddenly the whole Servlet container will go down! What should be done instead is to remove this "feature" which has no real meaning in a Servlet environment. I'm thus proposing to deprecate this feature. I don't even understand what use cases it brings. WDYT? Thanks -Vincent

13 years, 2 months

2
3
0 0

Re: [xwiki-devs] Access password of current user

by David Delbecq

Hello, I was hoping that somehow, when submitted via the form, password gets recorded until the end of the session. We can't afford, for the sake of user experience, to ask password every time user need to access a hidden system he is not even supposed to know is separate from the wiki. That's why we are writing some macro / components so that it's xwiki that access those system for him. This include various webservices, a documents storage and so on. We try to keep a single sign on policy. Of course, i don't want user password stored anywhere on disks, but keeping it in user session seems a good trade-of for me. I plan thus to create my onw xwikiauthservice that delegates to ldap service and store this in user session. ----- Mail original ----- De: "Jerome Velociter" <jerome(a)winesquare.net> À: "XWiki Developers" <devs(a)xwiki.org> Envoyé: Mardi 19 Juin 2012 11:53:42 Objet: Re: [xwiki-devs] Access password of current user Hi, Fortunately, you can't. You can only access/verify a hashed version of the password. Note that asking for a password again is not necessarily a bad UX, especially if it is to allow access to a sensitive area/operation. Cheers, Jerome. On Tue, Jun 19, 2012 at 11:39 AM, David Delbecq <david.delbecq(a)meteo.be> wrote: > > Hello, > > i am writing a component that need a password. Because this password will be the same for current user as the one he used to log-in, it would make for crappy interface ot ask it again to user. So i need to know how my component or a groovy script can access the username / password of current logged-in user. > > Thank you. > > > David Delbecq > > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs -- Jérôme Velociter Winesquare http://www.winesquare.net/ _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

13 years, 2 months

4
6
0 0

[xwiki-devs] glancing through the optimization process

by Paul Libbrecht

Hello XWiki community, we are about to deploy our XWiki 3.5.1(+ a bit) on www.curriki.org and... well... we need to be sure the data migration is going to happen so we are trying this on our staging server. The first failure happened: after more than one day, the process finally ended complaining about a disk full (it was 90% full, only with OS and DB). The process became very slow with update queries that took longer and longer to update. Ok, first lesson learned, I should plan with an amount of free disk space. (for the record: our XWiki has 300'000 documents, 250'000 being users, the rest being learning resources, groups' activities or application files. Our production servers (one db, one apache, one xwiki, is made of Sun Fire X4600 Intel) while our staging servers (same) is made of Sun Fire T 2000 Sparc (slow but robust!)). But I'd like to plan better so that we get a downtime below 3h hopefully. Caleb was kind enough to indicate me https://github.com/xwiki/xwiki-platform/tree/master/xwiki-platform-core/xwi… as the place where most of the refactorings are made. However, I could not find: * where "create index" queries are run: we could run them before the system goes down (the one on xwikiattrecyclebin took more than an hour) * which query we could zap (where it locked was actually at the following SQL query: SELECT DISTINCT x3.xwd_id FROM xwikidoc x3 LEFT JOIN xwikiobjects x4 ON x3.xwd_fullname = x4.xwo_name WHERE x3.xwd_date >= '2012-06-18 20:30:05' AND (x3.xwd_web = 'XWiki' OR x3.xwd_web LIKE 'Coll_%') AND x3.xwd_name NOT IN ('WebHome', 'Favorites') AND x4.xwo_classname IN ('XWiki.XWikiUsers', 'CurrikiCode.AssetClass') ORDER BY x3.xwd_date asc LIMIT 250 * what is the sequence and how I could monitor the progress? (what is the "name" of the logger member of R40000XWIKI6990DataMigration.java for example? (being injected, I can have no clue reading the source. thanks in advance Paul

13 years, 2 months

1
1
0 0

[xwiki-devs] Apply the sheet specified on the request only to the requested document

by Marius Dumitru Florea

Hi devs, I opened http://jira.xwiki.org/browse/XWIKI-7942 (thanks to Anca). I'd like to change the behaviour of the SheetManager to return the sheet specified on the request only if the passed document is the requested document. This was my initial intention when I introduced the parameter but I overlooked the fact that it will be used 'recursively' for all included/displayed documents within a sheet. I don't see any real use case for the current behaviour so I'm considering it a bug. If someone is relying on this behaviour or sees a use case for it then please speak. Thanks, Marius

13 years, 2 months

1
0
0 0

[xwiki-devs] Access password of current user

by David Delbecq

Hello, i am writing a component that need a password. Because this password will be the same for current user as the one he used to log-in, it would make for crappy interface ot ask it again to user. So i need to know how my component or a groovy script can access the username / password of current logged-in user. Thank you. David Delbecq

13 years, 2 months

2
1
0 0

[xwiki-devs] [ANN] XWiki Enterprise and XWiki Enterprise Manager 4.1 released

by Caleb James DeLisle

The XWiki Development team is proud to announce the second release of the 4.x cycle. This release brings Extension Manager improvements such as merging of configuration documents during extension upgrade, a more gentle learning curve by hiding internal documents from non-technical users, and lots of goodies for the developers such as easy sharing of variables between scripts in different languages. Download it hot off the press: http://www.xwiki.org/xwiki/bin/view/Main/Download Other new and notable features include: * Message sender macro for allowing users to send to the activity stream from any location. * Global and per-user timezone settings * Script access to load dependencies from the core using the Component Manager * Smarter velocity interpretation converts allows strings to be passed to methods which take enums * Stop run-away scripts after a configurable timeout * Shorthand HQL queries in the Query Manager For a full list with examples and explanations, check out the release notes: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWikiEnterpris… Thanks everyone who contributed to make the 4.1 cycle a success. Caleb

13 years, 2 months

4
6
0 0

[xwiki-devs] [VOTE] Stop filtering the filename in XWikiAttachment#setFilename

by Thomas Mortagne

Hi devs, Here is what XWikiAttachment#setFilename looks like public void setFilename(String filename) { filename = filename.replaceAll("\\+", " "); if (!filename.equals(this.filename)) { setMetaDataDirty(true); this.filename = filename; } this.reference = null; } Seriously ? That does not make any sense and there is not even a comment for it. I would go for removing this replaceAll and forget about anything that really expect this API to do something that bad and avoid retro-compatibility nightmare. WDYT ? Here is my +1. -- Thomas Mortagne

13 years, 2 months

4
4
0 0

[xwiki-devs] [Discussion] About hidden applications and how we find them

by Ecaterina Moraru (Valica)

Hi, XWIKI-7568 <http://jira.xwiki.org/browse/XWIKI-7568> - Implement mechanism to hide technical content added some big changes for me in the way we organize things inside XWiki, what we consider to be hidden or not and how we reach hidden applications. As a first visible change, now the Spaces gadget found on Main.WebHome doesn't display anymore spaces like 'AnnotationCode', 'ColorThemes', 'Invitation', 'Panels', 'Scheduler', 'Stats'. My main concern is that if something is not visible and accessible it will never be used and thus it doesn't exists. That's why I've created: XWIKI-7916 <http://jira.xwiki.org/browse/XWIKI-7916> - Integrate ColorThemes functionality inside Administration XWIKI-7920 <http://jira.xwiki.org/browse/XWIKI-7920> - Integrate Scheduler functionality inside Administration XWIKI-7919 <http://jira.xwiki.org/browse/XWIKI-7919> - Create an entry point for Stats inside Administration XWIKI-7918 <http://jira.xwiki.org/browse/XWIKI-7918> - Have an entry point for the Invitation application While some functionality may seem normal to be Admin only (also because some of the hidden spaces were about configuration), some is arguable: - 'ColorThemes' initially were supposed to be used also by normal users in their profile but this didn't made it in final implementation; - makes sense that maybe a normal user could create a 'Panel' but right now this is not possible from Panels.WebHome; - Invitation should be able to be used by both types of users, but without the setting of the server mail, the users will always receive an error; - Stats again could be used by both. What I would like is that things that are about configuration should always be integrated in the Administration. I am referring to the Scheduler configuration, Stats configuration, Search Suggest configuration, etc. The logic behind is that the Administration acts like an entry point for any configuration related actions. As Admin I shouldn't go outside Administration in order to achieve my configuration task (ex. XWIKI-7917<http://jira.xwiki.org/browse/XWIKI-7917> XWIKI-7921 <http://jira.xwiki.org/browse/XWIKI-7921> etc. ). Now adding configuration inside Administration still doesn't solve the problem on the entry point. As an administrator, after I've completed the configuration step, where do I find the application? As a normal user is the same question + how do I even know that applications exists? For this issue I've created XWIKI-7927 <http://jira.xwiki.org/browse/XWIKI-7927> - Create an entry point for all available applications inside the wiki This can be implemented as a gadget, as a panel or even as an Application Index (as a livetable or as a grid). Now another problem remaining is that of specifying if an application is intended for Advanced, Simple users or both. Who should see Stats app? All the users? Just advanced users? As a first step, the hidden feature works because 'advanced' applications will be considered 'hidden' for users. The problem is what we consider 'advanced' to mean. Is ColorThemes or Stats an advanced application? And is especially problematic since by default the Administrator has an 'advanced' + 'hidden' configuration, meaning that he will not be able to see by default ColorThemes or other configuration (but currently hidden) application that might be useful for him (he needs to know that the functionality exists somewhere). So he is an 'advanced' user that doesn't have visibility to 'advanced' applications. So IMO the hidden mechanism is great for hiding technical pages (pages like *Sheet, *Template, Macros, internal pages, etc.) from users. It doesn't matter if those pages exist (from an user's point of view) as long as there is an UI that integrates them. The bad part of the current status of the 4.1RC1 is that IMO we should not consider entire applications to be hidden. Internal pages of the 'Invitation' app should be hidden, but the WebHome (that contains the functionality and the UI) should be available/discoverable somewhere. In order for 'advanced' applications to not be displayed for normal users we should have another field that describes the application and this can be 'simple' or 'advanced' (and not rely just on the 'hidden'). XWIKI-7925 <http://jira.xwiki.org/browse/XWIKI-7925> - Have application descriptors for Application spaces So the only problem remaining (besides the actual implementation :) ) would be to discuss what applications are advanced (or even admin only) and what are not (thus available to the general population). Keep in mind that the current separation is now simple/advanced but we might need a user/developer/admin separation in order to better separate the task functionality of our current applications scopes (ex. since we might want to have admins only applications that should not be available to developers, both being advanced users). Thanks, Caty

13 years, 2 months

4
4
0 0

Re: [xwiki-devs] [GSoc] XDroid Platform

by sasinda rukshan

Thanks very much for the help on maven build. *About making a object from Blog.BlogPostClass and toXML()* A blog object is having properties of type other xobject classes. So to make the things general can we do a stripped down replication or make something similer to the java classes in com.xpn.xwiki.objects and its 2 sub packages .classes, .meta . We can make a document object representing a page and put a Blog.BlogPostClass object to its list of objects.We can convert them to simple xml model directly.If we want to post blog object we can post the Blog object.If the page does not exist we can put the page by getting the xml from the Document object. Then the things will be general not only for blog client app. Also we can have Type checking when we don't directly manipulate simplexml objects. i.e. XStringClass will define the attributes for it and likewise. I don't have a good idea on the above packages and classes. Specially why there are three classes for each XType ex: StringProperty, StringClass, StringMeta. It will be helpful if you can give an explanation. My draft solution is to do some simple thing as, XObject |____ XBoolean XObject |____XString XString has methods, toEmbedXML gives a <property><attribute/>...</property> string/ simpleXML objects toXML gives <object><id><ClassName>.......</object> for the same thing. Also XObject |_____ XBlogPost for(BlogPostClass and other 2 Meta,Property classes) I don't yet have a clear idea on this. May be I am wrong on this. Can you give me your idea here as well. How to approach the problem and what should the design be like? Thanks. Best Regards Sasinda. On Thu, Jun 7, 2012 at 9:28 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com>wrote: > As just did a commit with last version of android plugin and some > cleanup. Seems to work well. > > On Thu, Jun 7, 2012 at 12:19 PM, Thomas Mortagne > <thomas.mortagne(a)xwiki.com> wrote: > > BTW if you have quick questions it's probaly better to use IRC (I'm > > tmortgane on the channel and I'm on GMT+2 tome zone but you can ask > > anyone when I'm not around). See > > http://dev.xwiki.org/xwiki/bin/view/Community/IRC. > > > > On Thu, Jun 7, 2012 at 12:17 PM, Thomas Mortagne > > <thomas.mortagne(a)xwiki.com> wrote: > >> Not need to send this kind of mail privately to me. > >> > >> On Thu, Jun 7, 2012 at 5:33 AM, sasinda rukshan > >> <sasindarukshan(a)gmail.com> wrote: > >>> Thanks, > >>> The project is building perfectly well in eclipse (and runs well too) > [I > >>> configured the build paths for eclipse opening each module as a > project and > >>> giving project dependencies and etc.]. This is because android facet > and > >>> maven-android plugin for eclipse [m2e-android] (not the jayway androi > maven > >>> plugin)does not work together well. > >>> Maven build does not work with newer jayway android maven plugins > because of > >>> the simplexml library. I checked with another helloworld app that does > not > >>> have simplexml dependancy and have simplexml dependancy. When we have > the > >>> dependancy it does not work. Also when packaged with the beta version > maven > >>> plugin I get runtime error logs notifying that the exact classes > informed > >>> missed in the compile time for newer maven plugin are missing. But the > app > >>> is running ok. > >>> I will try with it some more and if I can't can you help me with it a > >>> little. > >> > >> Sure If it's just related to simplexml it's probably not much. I will > >> try to take a look today. At worst the version we are using right now > >> is working fine so you can continue with it anyway. > >> > >>> > >>> I looked at the Enterprise platform apis just to make my apis similar > when > >>> possible.Source code is not at all relevant to me. But as you say It > will be > >>> imperfect if I use its style heavily for the mobile version as well. > >> > >> Yes there is several issues here: > >> * most APIs in oldcore module are old and bad and we are trying to get > >> rif of them so better not getting too much attached to it ;) > >> * they are designed to run in an enironment with lots of resources and > >> don't care as much as a mobile API should about memory, etc. > >> > >>> > >>> > >>> Thank you. > >>> Best Regards. > >>> Sasinda. > >>> > >>> > >>> On Wed, Jun 6, 2012 at 1:03 PM, Thomas Mortagne < > thomas.mortagne(a)xwiki.com> > >>> wrote: > >>>> > >>>> On Tue, Jun 5, 2012 at 7:07 PM, sasinda rukshan > >>>> <sasindarukshan(a)gmail.com> wrote: > >>>> > Hi, > >>>> > *1: User Config Saving* > >>>> > * > >>>> > * > >>>> > Xwiki android can now save user login data. > >>>> > I refered > >>>> > http://platform.xwiki.org/xwiki/bin/view/AdminGuide/AccessWiki. > >>>> > Currently assuming the authority > >>>> > > >>>> > part(platform.xwiki.org< > http://platform.xwiki.org/xwiki/bin/view/AdminGuide/AccessWiki>) > >>>> > only > >>>> > as a unique wiki identifier. But in the > org.xwiki.android.entity.User I > >>>> > have the method > >>>> > setXWikiRealm(String url);: > >>>> > Here I have intended the meaning realm as the url root path for a > unique > >>>> > wiki instance. > >>>> > i.e. it should identify a wiki using path upto > >>>> > http://host/xwiki/wiki/wikialias/ > >>>> > But that functionality is not implemented.I just mailed this asking > for > >>>> > the > >>>> > opinion wether the usage of word realm was right here. > >>>> > Also do you have seperate users for wikis for path based wiki > access.Or > >>>> > are they the same with the main wiki *http://<host>/xwiki*. > >>>> > >>>> Both actually, you can have global users (which are the one on main > >>>> wiki) and local users. > >>>> > >>>> > *2: Entity model* > >>>> > * > >>>> > * > >>>> > About the convention for using C_ prefix for core entity tables. I > >>>> > was referring to make the android versions of these entities > >>>> > http://platform.xwiki.org/xwiki/bin/view/DevGuide/DatabaseSchemaand > >>>> > start > >>>> > there db prefixes with C_ > >>>> > This is because other apps may need to store some specific tables > needed > >>>> > for them. Rather than having a seperate DB schema for them we can > put > >>>> > those > >>>> > tables here as well prefixing them with <appname>_ . > >>>> > I added more entities like User as well to the core entities(table > >>>> > C_User).Also will implement a Log Entity(C_Log table) for logging > some > >>>> > important application activities(such as login attempts) But the > Log may > >>>> > be > >>>> > a little additional weight to the space and performance.I may > implement > >>>> > a > >>>> > generic DBCleaning service to clean the tables like Log, if I have > time. > >>>> > (Perhaps this description will resolve the confusion about the DB > >>>> > conventions. Sorry I was not very clear in that earlier mail. ;-).) > >>>> > > >>>> > I am sorry to say I am somewhat confused with all those entities in > >>>> > http://platform.xwiki.org/xwiki/bin/view/DevGuide/DatabaseSchema. > >>>> > >>>> The XWiki model is based on generic classes and objects wich is why > >>>> you see lots of tables (class properties, object properties , etc.). > >>>> There is no table for users for example, its an object of class > >>>> XWiki.XWikiUsers. > >>>> > >>>> > > >>>> > Any way to reduce my confusion > >>>> > I refered > >>>> > 1) XWiki Data > >>>> > Model<http://platform.xwiki.org/xwiki/bin/view/DevGuide/DataModel> > >>>> > : > >>>> > can you give me a link to a documentation that explains the > workflow > >>>> > of > >>>> > how a normal request is converted in to the requested page by the > >>>> > bin View action . So I can get a better understanding of how > classes , > >>>> > objects are used. > >>>> > >>>> Not sure there is one. but basically you get either: > >>>> * document content executed > >>>> * if a class sheet is defined for one of the document objects classes, > >>>> the class sheet is executed > >>>> * if a document sheet is defined for the documment, the document sheet > >>>> is executed > >>>> > >>>> That's pretty much all, then is a matter of free script and wiki > >>>> syntax to actually display the content. > >>>> > >>>> > 2) package com.xpn.xwiki.api: I don't need to consider this, do I? > >>>> > >>>> That's limited scripting API so you should not consider this. > >>>> > >>>> > 3) > >>>> > Cache< > http://extensions.xwiki.org/xwiki/bin/view/Extension/Cache+Module> > >>>> > : Need not implement similar component. Android OS does it nicely > for > >>>> > the > >>>> > REST responses > >>>> > but still don't have a clear picture on this. > >>>> > To save a blog doc > >>>> > option 1)Seems like I have to convert a document entity to relevent > >>>> > xwiki-model-simplexml entities and send to server. > >>>> > option 2) We also can edit the relevent simplexml model object > fields > >>>> > directly. (Looks a bad option to me.It does not hide the complexity > of > >>>> > lower levels for the client layer.Anyway my work load is reduced > with > >>>> > opt:2 ;-)) > >>>> > >>>> IMO you should not even look at > >>>> http://extensions.xwiki.org/xwiki/bin/view/Extension/Cache+Module and > >>>> instead look at how caching is usually done in Android. The idea is > >>>> not to port the xwiki-platform to Android IMO but to follow Android > >>>> standards to provide a library to manipulate XWiki model. > >>>> > >>>> You can set the annotation you want to the simplexml model but the > >>>> classes/methods should remain an exact copy of what's on > >>>> xwiki-platform-rest-model. The idea being that we could decide to > >>>> change the implementation from simplexml to anything (JAXB, gson, > >>>> etc.) without breaking anything. > >>>> > >>>> > > >>>> > > >>>> > *3: Development/architectural approach Change* > >>>> > * > >>>> > * > >>>> > I was first thinking for a addon like architecture for the XWiki > android > >>>> > app. We have the client.Main app (with all platfrom libs included) > and > >>>> > Blog > >>>> > app as a seperate apk. > >>>> > But here Blog app will need to have the platform lib also. That > would be > >>>> > a > >>>> > complete waste of space. But dynamically extending the app is lot > >>>> > easier. > >>>> > The client.Main app can add the activities defined in other apks in > to > >>>> > its > >>>> > launcher interface using android PackageManager class. > >>>> > > >>>> > > http://stackoverflow.com/questions/9236803/android-build-an-application-tha… > >>>> > But with this approach rises additional complexities. For example > naming > >>>> > conflicts in the Components library module when two apps have the > same > >>>> > library with same activities defined. Sync issues etc etc.... > >>>> > So we will go with single .apk approach. > >>>> > When going with single .apk we dont need a content provider to share > >>>> > config/ preferences data. So sharing module is now not needed. The > >>>> > client > >>>> > applications now can directly access the Configuration.java class to > >>>> > get/put configuration entries. > >>>> > Also since I am having a User entity a configuration like > >>>> > defaultUser(currently the admin user , hard coded in login.xml > layout > >>>> > file) > >>>> > will only be needed for the first use of the app. Otherwise users > need > >>>> > not > >>>> > configure a default user as the application now suggests the user > names > >>>> > and > >>>> > automatically fill the rest. > >>>> > >>>> Keep in mind that the main goal of this project is to provide tools > >>>> for any application to access an XWiki instance and manipulate its > >>>> datas easily an improving those libraries should always be the first > >>>> goal. Your blog application is here as a good demo and because it's > >>>> hard to design a library without using it. > >>>> > >>>> I really don't understand why you talk about naming conflict. Of > >>>> course a library should never provide a complete final activity but > >>>> only interface components (View), fragments or base activities to > >>>> extend. Putting those elements in an activity is each application job. > >>>> An activity is by definition unique so it has nothing to do in a > >>>> library. The complete activities in > >>>> > >>>> > https://github.com/xwiki-contrib/android-client/tree/master/xwiki-android-c… > >>>> should have never been there, it's actually a mistake. > >>>> > >>>> > > >>>> > *4: Plan for this week* > >>>> > >>>> As a priority you should really merge your branch as soon as you have > >>>> something building fine. So that it goes through Jenkins and deploy > >>>> snapshot build of what you do. Jenkins will tells you in live when > >>>> your project does not build anymore or if there is any test failing > >>>> and it allows anyone to very easily test the current test of the > >>>> client just by installing the apks on > >>>> http://maven.xwiki.org/snapshots/org/xwiki/android/. You need to have > >>>> something working and in good shape to succeed the GSOC so fixing when > >>>> you break something in your build should be your priority over adding > >>>> more features. > >>>> > >>>> Also as I commented in your commit you should be more careful on what > >>>> you commit. There is many binaries and Eclipse stuff in your branch. > >>>> > >>>> > * > >>>> > * > >>>> > Make a launch pad .We can launch XWiki Navigator, blog etc from > this. > >>>> > The > >>>> > launch pad is shown when we launch XWiki main client. > >>>> > Consider adding the WYSIWYG to my blog. It will be useless without > the > >>>> > ability to convert text formatting to xwiki syntax.So I may just > >>>> > integrate > >>>> > it and ignore the uselessness for now. > >>>> > >>>> Not exactly, you could actually reuse WYSIWYG service to send html and > >>>> let it convert it to wiki syntax. Note that you are not limited to > >>>> what you can find in the current Android library. This is just what > >>>> Chamika had the time to do. There is others REST (or not REST) server > >>>> interfaces you can use in your client or even add more if its generic > >>>> enough and make sense for something else than just Android client. > >>>> > >>>> > We currently don't have any config to save( Other than default user) > >>>> > config. I will add some demo config data and have a developer tools > app > >>>> > added to the above mentioned XWiki launch pad that can view/edit the > >>>> > config > >>>> > file. > >>>> > > >>>> > That will complete milestone 1. But it is not the Sharing > >>>> > module(intended > >>>> > to share data with other .apks).That is the configuration component > does > >>>> > not have a ContentProvider to share config data with other apks. > Also I > >>>> > will define a seperate class to have preferences which will be > edited by > >>>> > users. Config files are for configuration stuff and will be edited > by > >>>> > developers. Users have preferences files(natively supported by > android) > >>>> > to > >>>> > change app preferences. For example users will add the default login > >>>> > username as a preference.(This will invalidate the use of default > User > >>>> > entry in the config file which is used until the user edits his > >>>> > preferences) > >>>> > >>>> I'm fine with not sharing datas between applications but it does not > >>>> prevent the libraries to provide tools to manage those datas in a per > >>>> application basis. > >>>> > >>>> > > >>>> > Beg your pardon if the mail is too lengthy.;-) > >>>> > >>>> No problem, never too much information for this ;) > >>>> > >>>> > Thank you. > >>>> > Best Regards. > >>>> > > >>>> > Sasinda Rukshan. > >>>> > > >>>> > > >>>> > Best Regards. > >>>> > > >>>> > > >>>> > On Wed, May 30, 2012 at 1:11 PM, Thomas Mortagne > >>>> > <thomas.mortagne(a)xwiki.com>wrote: > >>>> > > >>>> >> On Wed, May 30, 2012 at 4:28 AM, sasinda rukshan > >>>> >> <sasindarukshan(a)gmail.com> wrote: > >>>> >> > Hi, > >>>> >> > I am studying ORM Lite these days. > >>>> >> > Please It would be comforting if you can confirm whether it is > worth > >>>> >> > the > >>>> >> > overhead to use ORM Lite. > >>>> >> > > >>>> >> > >>>> >> > http://logic-explained.blogspot.com/2011/12/using-ormlite-in-android-projec… > >>>> >> > http://ormlite.com/ > >>>> >> > ORM Lite features: > >>>> >> > Automatically Creates standard DAOs for an annotated entity. > >>>> >> > Coding will be lot easier. > >>>> >> > >>>> >> Remember it's a framework for a mobile platform so it has to remain > >>>> >> light and have good performances. I can see that Android version of > >>>> >> ormlite is very small but I never used it so I don't know if it's > good > >>>> >> or not. At least it seems petty active which is a good point so I > >>>> >> don't have anything against it. > >>>> >> > >>>> >> > > >>>> >> > Can you suggest how to name the entities. > >>>> >> > I am going to go with, > >>>> >> > <entity> org.xwiki.xdroid.data.User --> <table> C_USER > >>>> >> > >>>> >> Note that there is already a package name prefix and group id > defined > >>>> >> for the framework and it's org.xwiki.android as you can see on > >>>> >> https://github.com/xwiki-contrib/android-client. Why do you want > to > >>>> >> change it ? It's more consistent with > >>>> >> org.xwiki.commons/org.xwiki.rendering/org.xwiki.platform so I would > >>>> >> prefer to keep it that way unless you can give arguments. The goal > is > >>>> >> not to redo something completely but complete and improve the > existing > >>>> >> framework. > >>>> >> > >>>> >> Also as far as I can see there is already several things called > >>>> >> "xdroid" on Google play among which an application developer > >>>> >> (https://play.google.com/store/apps/developer?id=x-droid) and an > >>>> >> application ( > >>>> >> > >>>> >> > https://play.google.com/store/apps/details?id=com.gurudigitalsolutions.xdro… > >>>> >> ). > >>>> >> > >>>> >> > > >>>> >> > Thanks, > >>>> >> > Best Regards > >>>> >> > > >>>> >> > Sasinda. > >>>> >> > > >>>> >> > > >>>> >> > > >>>> >> > > >>>> >> > > >>>> >> > On Wed, May 30, 2012 at 7:42 AM, sasinda rukshan > >>>> >> > <sasindarukshan(a)gmail.com>wrote: > >>>> >> > > >>>> >> >> Hi, > >>>> >> >> > >>>> >> >> I am commiting my work to my fork > >>>> >> >> https://github.com/sasinda/android-client. > >>>> >> >> I ll request to pull it to xwiki-contrib later. > >>>> >> >> > >>>> >> >> I was running in a wrong path these days. Wanted to save login > >>>> >> >> history > >>>> >> and > >>>> >> >> suggest login. I was going to do it using an xml file (login > >>>> >> attempts.xml). > >>>> >> >> Now it seems database is better. > >>>> >> >> Any way before I go wrong again I will say what I am going to > do. > >>>> >> >> I am going to enforce following conventions.These are not yet > >>>> >> >> needed, > >>>> >> >> considered the small scale.But when the system grows it would be > >>>> >> >> nice to > >>>> >> >> have them to avoid confusions. > >>>> >> >> *Database prefixes for:* > >>>> >> >> *Platform tables (can begin with appropriate prefix)* > >>>> >> >> AD_ //application dictionary : don't know when it will be > needed ;-) > >>>> >> >> C_ //core functionality > >>>> >> >> *Client Applications.* > >>>> >> >> X<App name prefix> ex: XBLOG_ for Blog app// All client add > in > >>>> >> modules > >>>> >> >> must begin with table prefix X(for xwiki and ordering) + App > name. > >>>> >> This is > >>>> >> >> for my blog. > >>>> >> >> > >>>> >> >> I will create > >>>> >> >> C_User for user data. > >>>> >> >> C_LoginAttempt for saving login attempts. > >>>> >> >> > >>>> >> >> From C_LoginAttempt I can filter uniqe login combinations and > give > >>>> >> >> suggestions in the login UI component. Also save the history. > >>>> >> >> > >>>> >> >> All saved data for blog app will be linked to a perticular > login : > >>>> >> >> User, > >>>> >> >> XWiki server. > >>>> >> >> But only a single user will be most probably using his personal > >>>> >> >> device. > >>>> >> So > >>>> >> >> above will be relevant only when he has multiple wikis. > >>>> >> >> > >>>> >> >> Best Regards, > >>>> >> >> Sasinda Rukshan. > >>>> >> >> > >>>> >> >> > >>>> >> >> > >>>> >> >> > >>>> >> >> > >>>> >> >> On Sun, May 27, 2012 at 5:43 PM, Chamika Weerasinghe < > >>>> >> chamikaw(a)gmail.com>wrote: > >>>> >> >> > >>>> >> >>> On Fri, May 25, 2012 at 1:25 AM, Jerome Velociter < > >>>> >> jerome(a)winesquare.net > >>>> >> >>> >wrote: > >>>> >> >>> > >>>> >> >>> > On Thu, May 24, 2012 at 6:09 PM, Thomas Mortagne > >>>> >> >>> > <thomas.mortagne(a)xwiki.com> wrote: > >>>> >> >>> > > On Thu, May 24, 2012 at 5:52 PM, sasinda rukshan > >>>> >> >>> > > <sasindarukshan(a)gmail.com> wrote: > >>>> >> >>> > >> Hi all, > >>>> >> >>> > >> I am starting this thread for my XWiki Android Platform > >>>> >> >>> > >> Project. > >>>> >> >>> > >> > >>>> >> >>> > >> Please check whether following are OK. > >>>> >> >>> > >> [1] INFO > >>>> >> >>> > >> I tried to start my new modules with the > >>>> >> >>> de.akquinet.android.archetypes: > >>>> >> >>> > >> android-quickstart:1.0.8. (added eclipse plugins m2e, > >>>> >> >>> > >> m2e-android[a.k.a *Android > >>>> >> >>> > >> Configurator* ]). But this seems buggy in eclipse. > >>>> >> >>> > >> Any way the earlier project has not followed the above > >>>> >> >>> > >> archtype > >>>> >> >>> either. > >>>> >> >>> > So > >>>> >> >>> > >> I am going to write pom.xml manually for my each module. > >>>> >> >>> > >> > >>>> >> >>> > >> [2] ADVICE NEEDED > >>>> >> >>> > >> xwiki-rest-model module contains 2 submodules > >>>> >> >>> > >> |-- xwiki-rest-model-gson ( gson should be corrected to > >>>> >> >>> > >> json) > >>>> >> >>> > > > >>>> >> >>> > > No the g is not a mistake, it's a model to be used with the > >>>> >> >>> > > gson > >>>> >> >>> > > library (http://code.google.com/p/google-gson/). See > >>>> >> >>> > > > >>>> >> >>> > > >>>> >> >>> > >>>> >> > >>>> >> > http://extensions.xwiki.org/xwiki/bin/view/Extension/Google+Android+Client#… > >>>> >> >>> > . > >>>> >> >>> > > > >>>> >> >>> > >> |-- xwiki-rest-model-simplexml > >>>> >> >>> > >> I think the xwiki-rest-model-gson is redundant. The > classes > >>>> >> >>> > >> in xwiki-rest-model-simplexml is added with simple xml > >>>> >> annotations, > >>>> >> >>> > >> otherwise both modules have same classes. There is no > problem > >>>> >> >>> > >> with > >>>> >> >>> the > >>>> >> >>> > >> added annotations for using the same model objects for > Json > >>>> >> >>> > >> REST > >>>> >> web > >>>> >> >>> > >> services. And I intend to add my JPA (ORMLite library for > >>>> >> >>> persistence) > >>>> >> >>> > >> annotations on top of it. > >>>> >> >>> > >> Shall I re-factor them to a single module > xwiki-rest-model. > >>>> >> >>> > > > >>>> >> >>> > > No keep them separated, the idea is that both are useful > tool > >>>> >> >>> > > to be > >>>> >> >>> > > used by someone else that might be moved to xwiki-platform > at > >>>> >> >>> > > some > >>>> >> >>> > > point along with the current xwiki-rest-model (to be > renamed to > >>>> >> >>> > > xwiki-rest-model-jaxb). > >>>> >> >>> > > > >>>> >> >>> > > Chamika initially started with gson and since XWiki REST > JSON > >>>> >> >>> > > representation had some limitation he moved to XML > >>>> >> >>> > > representation. > >>>> >> >>> > > Maybe at some point Android will have native support for > jaxb > >>>> >> >>> > > which > >>>> >> >>> > > would obviously be the easier for us (embedding jaxb is > not an > >>>> >> option > >>>> >> >>> > > in mobile world where size it still pretty important > especially > >>>> >> >>> > > on > >>>> >> >>> > > phones). Maybe it's already the case on most recent > versions > >>>> >> >>> > > like > >>>> >> 4.0 > >>>> >> >>> > > I don't know. > >>>> >> >>> > > >>>> >> >>> > There's also Jackson that could be tried for JSON > >>>> >> >>> > deserialization, if > >>>> >> >>> > said limitations are actually GSON limitations. > >>>> >> >>> > > >>>> >> >>> GSON wasn't the limitation. > >>>> >> >>> It was XWiki RESTful API which doesn't support JSON in some > cases. > >>>> >> >>> So > >>>> >> it's > >>>> >> >>> safe to go with xml. > >>>> >> >>> > >>>> >> >>> > > >>>> >> >>> > Having full JAXB support sound a bit overweight for such an > >>>> >> >>> > "embedded > >>>> >> >>> > API", even if one day it is natively supported by Android. > What's > >>>> >> >>> > important is to have an easy and fast deserialization, IMO. > >>>> >> >>> > The only advantage I can see of going JAXB would be in > re-using > >>>> >> >>> > the > >>>> >> >>> > exact representations and body readers/writers from XWiki > core. > >>>> >> >>> > But > >>>> >> >>> > you probably don't even want to do that since it would mean > >>>> >> >>> > dragging > >>>> >> >>> > XWiki core with you :) > >>>> >> >>> > > >>>> >> >>> > Jerome > >>>> >> >>> > > >>>> >> >>> > > > >>>> >> >>> > >> > >>>> >> >>> > >> [3] INFO > >>>> >> >>> > >> I had to change some pom.xml s. As the current project > at: > >>>> >> >>> > >> https://github.com/xwiki-contrib/android-client.git does > not > >>>> >> build. > >>>> >> >>> > Error > >>>> >> >>> > >> with parent pom.xml coordinates. > >>>> >> >>> > > > >>>> >> >>> > > You probably did not setup you maven install properly since > >>>> >> >>> > > what's > >>>> >> on > >>>> >> >>> > > https://github.com/xwiki-contrib/android-client.git build > >>>> >> perfectly > >>>> >> >>> as > >>>> >> >>> > > you can see on > >>>> >> http://ci.xwiki.org/view/All/job/xwiki-android-client/ > >>>> >> >>> > > which run a build every time something changes on the git > >>>> >> repository.. > >>>> >> >>> > > You should look at > >>>> >> >>> > > http://dev.xwiki.org/xwiki/bin/view/Community/Building. > >>>> >> >>> > > > >>>> >> >>> > >> > >>>> >> >>> > >> > >>>> >> >>> > >> Thank you > >>>> >> >>> > >> Best Regards. > >>>> >> >>> > >> Sasinda Rukshan > >>>> >> >>> > >> _______________________________________________ > >>>> >> >>> > >> devs mailing list > >>>> >> >>> > >> devs(a)xwiki.org > >>>> >> >>> > >> http://lists.xwiki.org/mailman/listinfo/devs > >>>> >> >>> > > > >>>> >> >>> > > > >>>> >> >>> > > > >>>> >> >>> > > -- > >>>> >> >>> > > Thomas Mortagne > >>>> >> >>> > > _______________________________________________ > >>>> >> >>> > > devs mailing list > >>>> >> >>> > > devs(a)xwiki.org > >>>> >> >>> > > http://lists.xwiki.org/mailman/listinfo/devs > >>>> >> >>> > > >>>> >> >>> > > >>>> >> >>> > > >>>> >> >>> > -- > >>>> >> >>> > Jérôme Velociter > >>>> >> >>> > Winesquare > >>>> >> >>> > http://www.winesquare.net/ > >>>> >> >>> > _______________________________________________ > >>>> >> >>> > devs mailing list > >>>> >> >>> > devs(a)xwiki.org > >>>> >> >>> > http://lists.xwiki.org/mailman/listinfo/devs > >>>> >> >>> > > >>>> >> >>> _______________________________________________ > >>>> >> >>> devs mailing list > >>>> >> >>> devs(a)xwiki.org > >>>> >> >>> http://lists.xwiki.org/mailman/listinfo/devs > >>>> >> >>> > >>>> >> >> > >>>> >> >> > >>>> >> > _______________________________________________ > >>>> >> > devs mailing list > >>>> >> > devs(a)xwiki.org > >>>> >> > http://lists.xwiki.org/mailman/listinfo/devs > >>>> >> > >>>> >> > >>>> >> > >>>> >> -- > >>>> >> Thomas Mortagne > >>>> >> _______________________________________________ > >>>> >> devs mailing list > >>>> >> devs(a)xwiki.org > >>>> >> http://lists.xwiki.org/mailman/listinfo/devs > >>>> >> > >>>> > _______________________________________________ > >>>> > devs mailing list > >>>> > devs(a)xwiki.org > >>>> > http://lists.xwiki.org/mailman/listinfo/devs > >>>> > >>>> > >>>> > >>>> -- > >>>> Thomas Mortagne > >>> > >>> > >> > >> > >> > >> -- > >> Thomas Mortagne > > > > > > > > -- > > Thomas Mortagne > > > > -- > Thomas Mortagne >

13 years, 2 months

2
5
0 0

[xwiki-devs] Groovy Console Extension compatible with XWiki 3.5?

by Niels Mayer

Is there a version of the Groovy Console ( http://extensions.xwiki.org/xwiki/bin/view/Extension/Groovy+Console+Applica… ) that is compatible with XWiki 3.5? When I try to run it, I see missing icons ( referencing old skins, which I fixed), but now get the following JavaScript errors after attempting to execute my Groovy code: Uncaught ReferenceError: CodeMirror is not defined var editor = CodeMirror.fromTextArea('script', { And "Uncaught TypeError: Cannot call method 'getCode' of undefined" var ajx = new Ajax.Request("$scriptDoc.getURL('save')" , { parameters: {"XWiki.ConsoleScriptClass_${scriptObj.number}_code":editor.getCode(), "ajax":"1"}, onComplete:function(transport){ $('saveLoading').addClassName("hidden"); $('saveStatus').removeClassName("hidden"); $('saveStatus').innerHTML = "Saved !"; var foo = new Effect.Highlight('saveStatus'); setTimeout(function(){ $('saveStatus').innerHTML = ""; $('saveStatus').addClassName("hidden"); }, 5000); } I guess I could keep plugging away and trying to fix this, but was wondering whether there's a newer version of the Groovy Console compatible w/ XWiki 3.5 and beyond, or is there some simple fix to the problems outlined above? Seems like this has been noted as a problem previously: http://lists.xwiki.org/pipermail/users/2011-October/020745.html I attempted installing 'SyntaxHighlighting' (says its "CodeMirror based syntax highlighting ...") and noticed it now adds new error at startup in the GroovyConsole: Uncaught TypeError: Object function a(f,g){if(g.dumbTabs){g.tabMode="spaces"}else{if(g.normalTab) Suggesting problems w/ this extension as well. I do note that my existing scripts now have pretty syntax highlighting... so it is working. Unfortunately, it also forces the wiki-code editor to appear below the wysiwyg and makes the wysiwyg area too small. So I uninstalled it and my Wysiwyg now works as before.... Any way of getting Groovy Console functionality working? Seems like a great way to work with cloud-based XWiki installs, such as mine... Thanks, -- Niels http://www.nielsmayer.com

13 years, 2 months

3
6
0 0

[xwiki-devs] [VOTE] Release a 4.0.1

by Thomas Mortagne

We have some important issue fixed after 4.0 so it would be nice to release a 4.0.1 before 4.1 final is out. WDYT ? Here is my +1. -- Thomas Mortagne

13 years, 2 months

7
10
0 0

[xwiki-devs] [Ideas] Some thoughts about Extension Manager's future

by Ecaterina Moraru (Valica)

Hi, I want to list some ideas about Extension Manager that come to my mind. I'm sure others thought about them already or will find the time to make some other suggestions: 1) Filtering core extensions Would be nice to be able to view preinstalled applications with EM. Right now everything that comes preinstalled is found inside 'Core extensions'. There are a lot of technical extensions, but there are also some extensions that could be of general knowledge. For example it would be nice to see what functionality a default wiki has in terms of applications and macros (even nicer if we think about future flavored packages). This would allow the administrator to quickly scan and customize the tools at his disposal. Maybe it would be interesting to have some filtering functionality. This way I could filter for applications and see that I have preinstalled 'Activity Stream', 'Annotations', 'Search', 'WYSIWYG', 'Message Stream', etc. and if I filter for macros I could get 'Chart macro', 'Box macro', 'Display macro', 'Message macro', etc. 2) Enable/Disable applications from inside EM Another idea is for the EM to sustain enable/disable actions for installed/core applications/macros. Right now applications like 'Annotations', 'Search Suggest', 'Message Stream', even 'OpenOffice Server' have special settings that permit to enable ('activate') them. This functionality could be covered by the EM and not display anymore special administration sections for each applications. 3) Integrate application configuration inside EM If EM will manage installed applications and would also allow the enabling/disabling part, than is normal that the application configuration should be made also from inside the EM and not as a separate Administration component. Although all things in XWiki are extensions and components, we would need to get along what the lightest version of xwiki would contain (in terms of functionality and not components). For this default functionalities (Users, Rights, Localization, Presentation, Import/Export, etc.) the Administration sections would be still used, since they could be considered core elements and not something that can be disabled or uninstalled. Maybe all the thoughts I am writing here could also be solved if we rewrite some functionality like 'Activity Stream', 'Annotations', some macros, etc. and not display them anymore as 'Core Extensions' but rather as 'Installed Extensions'. Thanks, Caty

13 years, 2 months

3
2
0 0

[xwiki-devs] xredirect parameter after an upload action

by Paul Libbrecht

Hello developers, I seem to see a regression whereby a POST to an /xwiki/bin/upload/ request no more uses the xredirect parameter and simply redirects to the page. Is this a known change? Is it supposed to have been working being undocumented and can try to find a fix? Or should I simply try to adjust the client (tremble tremble). thanks in advance Paul

13 years, 3 months

2
6
0 0

[xwiki-devs] [UX][Proposal] Improvements for WYSIWYG macros

by Ecaterina Moraru (Valica)

Hi, This is a proposal regarding the WYSIWYG macros: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MacrosOptions Other discussions: - Making it user-friendly to edit pages with macros for new users (was Re: Need some Help & Explanations) http://xwiki.markmail.org/thread/rnhe6tl3x7snquz7 Thanks, Caty

13 years, 3 months

5
6
0 0

[xwiki-devs] Extension management - Questions

by Gianluca Sabena

Dear all, some notes about my recent upgrade from 3.5 wiki farm to a 4.0 -- Sysem -- * Xwiki 4.0 farm (the old way, independent farm) * Jetty package that you provided xwiki-manaer-mysql-4.0 * 4 wikis (2 active, one template and the manager) * File attachments on filesystem -- Question -- 1) After I have upgraded from xem 3.5 to xem 4.0 all previously installed extensions have been removed from XEM control panel (but extension pages are still present) - minor bug, I have solved it reinstalling all extensions. 2) Since XEM 3.5 xwiki-manager can setup two different kind of multiple wikis: a) workspaces b) the old way wikifarm. - What is exactly the difference between that two? - XEM home page suggests to create workspaces and the old wikifarm is placed in a sub page, this create some confusion. I would prefer to have both options on the home page with some notes that explain differences. Personally I use the wiki farm (independent wikis). 3) In wikifarm (independent wikis) management of extensions is not clear. - If I install an extension from XEM it is installed in all sub-wikis, but if I remove it, it is removed only from XEM and not from sub-wikis (pages are still present but extension disappear form sub-wikis control panel, so it is impossible to completely remove them) - If I install an extension in sub-wiki, it is listed in XEM, but if I select it I see many errors. -- Bugs -- - One of the two wiki is constantly loosing web preferences settings (skins and localization template), no error in file log, really annoying and hard to debug. - Since webpreferences settings are lost, it is impossible to know what extensions were installed -- Workaround -- - Is it possible to have multiple wiki (completely independent) without using Xem? -- My proposal -- - If an extension is installed in XEM it can be removed only from XEM and this remove the extension form all sub-wikis (we could delete pages and send them in the recycler bin for better security) - If an extension is installed in sub-wikis it is only listed in the relative control panel of that wiki Thank you, Gianluca

13 years, 3 months

2
1
0 0

Re: [xwiki-devs] [xwiki-users] Panels backward compatibility

by Anca Luca

On 06/13/2012 06:09 PM, Sergiu Dumitriu wrote: > On 06/13/2012 09:17 AM, Vincent Massol wrote: >> >> On Jun 13, 2012, at 2:52 PM, Anca Luca wrote: >> >>> On 06/13/2012 02:44 PM, Vincent Massol wrote: >>>> On Jun 13, 2012, at 2:39 PM, Anca Luca wrote: >>>> >>>>> On 06/13/2012 01:52 PM, Raluca Stavro wrote: >>>>>> Hi, >>>>>> >>>>>> On Wed, Jun 13, 2012 at 2:15 PM, Vincent >>>>>> Massol<vincent(a)massol.net> wrote: >>>>>> >>>>>>> On Jun 13, 2012, at 12:44 PM, Raluca Stavro wrote: >>>>>>> >>>>>>>> I'm resending this mail by using the right subject pattern. >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> I am trying to upgrade an old XEM to 3.5.1. >>>>>>>> In this XEM there are some custom panels which have been >>>>>>>> converted to 2.0 >>>>>>>> syntax and contain code like this: >>>>>>>> >>>>>>>> {{velocity}} >>>>>>>> {{html}} >>>>>>>> #panelheader("...") >>>>>>>> ... >>>>>>>> #panelfooter() >>>>>>>> {{/html}} >>>>>>>> {{/velocity}} > > Do the panels really need the {{html}} wrapper? > If no, then you must remove it. > If yes, then you should consider rewriting them using wiki syntax > only, then remove the {{html}} wrapper. > If you can't do that, then just move the wrapper inside the > panelheader/footer. > > You can do that automatically with a script. > >>>>>>>> Because since 2.7.2 panel macros were converted to 2.0 syntax, >>>>>>>> because >>>>>>>> panel macros from inside macros.vm were modified by calling >>>>>>>> {{html}} wiki >>>>>>>> macro and because we can't use nested {{html}} macros without >>>>>>>> wiki="true" >>>>>>>> parameter, I don't know how to fix this issue besides modifying >>>>>>>> panel >>>>>>> code. > > I don't understand this. Are you saying that in macros.vm #panelheader > uses {{html}}? That's not true, the panelheader/footer macros only use > wiki syntax, not {{html}}. The problem isn't that nested {{html}} > macros don't work, but that wiki syntax doesn't work in {{html}} > without wiki="true". > >>>>>>>> This XEM has more than 70 wikis and this I can't just modify >>>>>>>> all custom >>>>>>>> (converted to 2.0 syntax) panels manually. >>>>>>>> Is there a nice solution to this problem ? >>>>>>> Idea 1: >>>>>>> ====== >>>>>>> >>>>>>> Add a new #panelheaderold macro in macros.vm and replace all >>>>>>> calls of >>>>>>> #panelheader to #panelheaderold in your panels (easy to do with >>>>>>> a XWQL >>>>>>> query and 3 lines of scripts). >>>>>>> >>>>>>> Slowy migrate panels to new syntax. >>>>>>> >>>>>>> Note: >>>>>>> ===== >>>>>>> >>>>>>> Actually in the future we need to add a new {{panel}} macro, >>>>>>> something >>>>>>> like: >>>>>>> >>>>>>> {{panel style=".." title="…"}} >>>>>>> … content here … >>>>>>> {{/panel}} >>>>>>> >>>>>>> Idea 2: >>>>>>> ====== >>>>>>> >>>>>>> Create a custom Panel wiki macro (give it a name other than >>>>>>> "panel"!), >>>>>>> search for: >>>>>>> {{velocity}}{{html}}#panelheader….#panelfooter{{/html}}{{/velocity}} >>>>>>> (use >>>>>>> a regex) >>>>>>> >>>>>>> Replace with your panel macro. >>>>>>> >>>>>>>> Should I open an issue on Jira ? >>>>>>> Nope >>>>> So this means that none of the macros in macros.vm are API? >>>>> Which means that there is no API to make a panel header consistent >>>>> with the panel headers of the default panels? >>>> Good point. Macros in macros.vm are supposed to be APIs and it >>>> means we broke the backward compatibility at some point in the past >>>> (2.7 as suggested by Raluca). > > The macros still work for both xwiki/1.0 and xwiki/2.x panels. What > doesn't work is putting the whole panel content inside a {{html}} > block, without any wiki parsing. > > The problem was that there was a misunderstanding of the macros > behavior. The macros were supposed to work well in wiki syntax. > Initially, that meant the only xwiki syntax, which did mix HTML with > the rest of the wiki and velocity syntax. When new wiki syntaxes were > introduced and the macros were updated, the behavior remained the > same: the #panelheader/footer macros work well in both xwiki/1.0 and > xwiki/2.x syntaxes. But pure HTML isn't really a wiki syntax. The fact > that for a few releases the macros worked in pure HTML embedded in an > xwiki/2.0 document, but not directly in a xwiki/2.0 document, was a > bug, not a contract. > Unfortunately some developers did rely on this bug. I wouldn't call it a bug, because if we do so, then we can argue that it's a bug that has been there for at least one major cycle, and that macros.vm is still not stable according to http://jira.xwiki.org/browse/XWIKI-6062 so we might still have "bugs" about it (and that is for about 2.5 major cycles, which is a bit too much from my point of view). What I would say about this is that apparently we don't know / have a convention about how should the macros in macros.vm be used: with syntax interpreted or not, in an html macro or not. This is where the confusion comes from: while the old panelheader macro _needed_ html macro (potentially with syntax activated), the current one needs _only wiki syntax_ (potentially in an html macro). There is a context which satisfies both (html macro with wiki syntax activated) but it was not documented anywhere, I'm not even sure it is _the rule_ for macros in macros.vm, so people used "what it worked", in this case a plain simple html macro whose wiki parameter defaults to false. The wysiwyg macros in macros.vm, for example, I would say they need to be called in a html macro with syntax switched off, but it's just a guess, looking at the code. I think we need to: 1/ make a decision about what is API from macros.vm 2/ make a decision about what _was_ API from macros.vm and keep it working as it used to 3/ document how an API macro should be used, either by having a rule or by at least writing in its own documentation in macros.vm what context it expects (note that even if we document it, if we cannot enforce it, chances are that people will use "what it works"...) To me, all these above are unclear and until they are, from how it feels to me, it's very hard to call something a bug or a backwards compatibility break. Thanks, Anca > >>> 3.2 M1 >>> https://github.com/xwiki/xwiki-platform/commit/2e4b54267b9bf4048c14fdf14b6a… >>> http://jira.xwiki.org/browse/XWIKI-6504 >>> It's interesting that the API Breakage section of the 3.2M1 release >>> notes says only "[TODO]" >>> http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWikiEnterpris… >>> ... :) >> >> bad bad… >> >> Who was the RM? :) >> >> -Vincent >> >>> Anca >>> >>>> >>>> We should probably have introduced new macros instead when we >>>> introduced the conversion to 2.0 syntax. >>>> >>>> Now since this is very old we need to decide what we want to do at >>>> this point. >>>> >>>> Thanks >>>> -Vincent >>>> >>>>> Thanks, >>>>> Anca >>>>> >>>>>> So there is no other way to fix this issue but by modifying the >>>>>> code inside >>>>>> panels. >>>>>> Thank you, Vincent. >>>>>> >>>>>> Raluca. >>>>>> >>>>>> >>>>>>> Thanks >>>>>>> -Vincent > >

13 years, 3 months

2
1
0 0

[xwiki-devs] Can not opeaate in panel wizard

by liujinlong5788

Hello , I want to trun to both columns layout ,but in the panel wizard the save in new layout and revert button can't be pressed down , I mean I click it but nothing happened. I use XWiki 3.5,loggin in with admin user , and I am sure I havn't done any change about this wizard . It's so strange . Do you have any suggestion about this ? Do I need to change the configuration to do this ? Thank you .

13 years, 3 months

1
0
0 0

[xwiki-devs] Nllpointerexception testing macro

by David Delbecq

Hello, i try to test a macro in a maven project created using maven archetype. It has .test files and an IntegrationTests class. Where running, it crashed due to nullpointerexception when trying to, probably, find out current user? Is ther some configuration i am missing? java.lang.NullPointerException: null at com.xpn.xwiki.doc.DefaultDocumentAccessBridge.getCurrentUser(DefaultDocumentAccessBridge.java:981) ~[xwiki-platform-oldcore-3.2.jar:na] at org.xwiki.component.internal.UserComponentManager.getKey(UserComponentManager.java:74) ~[xwiki-platform-component-multi-3.2.jar:na] at org.xwiki.component.internal.AbstractGenericComponentManager.getComponentManager(AbstractGenericComponentManager.java:72) ~[xwiki-platform-component-multi-3.2.jar:na] at org.xwiki.component.internal.DelegateComponentManager.lookup(DelegateComponentManager.java:103) ~[xwiki-platform-component-multi-3.2.jar:na] at org.xwiki.component.internal.DelegateComponentManager.lookup(DelegateComponentManager.java:103) ~[xwiki-platform-component-multi-3.2.jar:na] at org.xwiki.rendering.internal.macro.DefaultMacroManager.getMacro(DefaultMacroManager.java:132) ~[xwiki-rendering-transformation-macro-3.2.jar:na] at org.xwiki.rendering.internal.transformation.macro.MacroTransformation.getHighestPriorityMacro(MacroTransformation.java:232) ~[xwiki-rendering-transformation-macro-3.2.jar:na] at org.xwiki.rendering.internal.transformation.macro.MacroTransformation.transformOnce(MacroTransformation.java:152) ~[xwiki-rendering-transformation-macro-3.2.jar:na] at org.xwiki.rendering.internal.transformation.macro.MacroTransformation.transform(MacroTransformation.java:141) ~[xwiki-rendering-transformation-macro-3.2.jar:na] at org.xwiki.rendering.internal.transformation.DefaultTransformationManager.performTransformations(DefaultTransformationManager.java:81) ~[xwiki-rendering-api-3.2.jar:na] at org.xwiki.rendering.test.integration.RenderingTest.runTestInternal(RenderingTest.java:133) [xwiki-rendering-test-3.2.jar:na] at org.xwiki.rendering.test.integration.RenderingTest.execute(RenderingTest.java:103) [xwiki-rendering-test-3.2.jar:na] David Delbecq

13 years, 3 months

2
1
0 0

[xwiki-devs] Some quesiton regarding development of xwiki macro / extensions / plugins

by David Delbecq

Hello, To customize our entreprise wiki, we have identified a few plugins / macros that we need to develop. I have checked the online xwiki documentation / tutorial, but i find them quite uncomplete, so here i am with my questions :) 1) It is my understanding that, if my macro need some specific javascript (eg jquery.js) and css, i must use xwiki skin extension. While i can find easily how to create xwiki velocity code that use those extension, i found no explanation on how to do this in java from within "public List<Block> execute(T parameters, String content, MacroTransformationContext context)"? Where can i find example of embedding javascript/css inside a java macro jar or xar? 2) Extensions are provided as xar, maven archetype for xwiki java macro generates a .jar. How do i generate a xar with maven so that in one archive i have both my macro, the css and the js? 3) Most extension referenced on xwiki main site are open source, but where are the source? I can only find the compiled xar files on download 4) Is there some recommanded way to pass complex parameters to macros? I need to create some dynamic menu that will get as parameter a list of node + links + icon to show + subnodes + for each subnodes icons / links + subsubnode etc. Is it good practice to just put some kind of json in the body of macro, something like {{mymenu width="200px"}} [ { name: "node1", link: "MySpace.MyPage1", icon: "somelinktoanattachement"} , { name: "node2", link: "MySpace.MyPage2", icon: "somelinktoanattachement"}, { name: "node3", link: "MySpace.MyPage3", submenu: [ { name: "node3.1", link: "MySpace.MyPage31", icon: "somelinktoanattachement"}, { name: "node3.2", link: "MySpace.MyPage32", icon: "somelinktoanattachement"} ] } ] {{/mymenu}} And in this case, are there already some stock xwiki methode to transform json into objet array? Thank you, David Delbecq

13 years, 3 months

4
4
0 0

[xwiki-devs] [discussion] Connector feature for XWiki

by Ludovic Dubost

Hi Devs, I'd like to start a discussion about a Connector module for XWiki. XWiki is a great tool to create, edit and organize information. But while we can use macros to display external data, many XWiki's organization (such as the livetable), editing and viewing features can only be used for data stored in the XWiki System. However from time to time we've seen that it would be really interesting to: - allow editing/viewing of data from external systems using the XWiki form system - using livetable and search on external data I've been thinking for a while that we can achieve that in XWiki by transforming data read using an external API into XWiki Documents and then use the XWiki APIs to display that data. We can also implement livetable backends that would transform the livetable filters into query supported by the external tool. And if all this could be implemented as a "Connector Interface" most of the presentation code would be generic and we could develop and install connectors and magically you could make use of the XWiki development system to display, present and create forms to edit data. I've made a prototype for Salesforce and JIRA that shows the concept and what the API could be (in this case in Groovy) and wrote a design document that explains the system and the open questions: http://dev.xwiki.org/xwiki/bin/view/Design/ConnectorModule In my view this system is super powerfull if we can build it in the XWiki Core so that the view/edit/save/search can be hooked to the connector so that from the user experience the system is transparent to the user. WDYT ? Could the devs provide some insight of what the right architecture should be for such a feature. Ludovic -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

13 years, 3 months

3
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs