June 2012 - xwiki-devs@xwiki.org

Re: [xwiki-devs] [GSoC] Responsive Skin
by Jonathan Solichin 19 Jun '12

19 Jun '12

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

2 1

[xwiki-devs] [VOTE] Add extension id in the MANIFEST.MF in WAR distributions
by Thomas Mortagne 19 Jun '12

19 Jun '12

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

6 11

[xwiki-devs] DB Migration systems uses System.exit! Remove it
by Vincent Massol 19 Jun '12

19 Jun '12

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

2 3

Re: [xwiki-devs] Access password of current user
by David Delbecq 19 Jun '12

19 Jun '12

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

4 6

[xwiki-devs] glancing through the optimization process
by Paul Libbrecht 19 Jun '12

19 Jun '12

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

1 1

[xwiki-devs] Apply the sheet specified on the request only to the requested document
by Marius Dumitru Florea 19 Jun '12

19 Jun '12

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

1 0

[xwiki-devs] Access password of current user
by David Delbecq 19 Jun '12

19 Jun '12

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

2 1

[xwiki-devs] [ANN] XWiki Enterprise and XWiki Enterprise Manager 4.1 released
by Caleb James DeLisle 19 Jun '12

19 Jun '12

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

4 6

[xwiki-devs] [VOTE] Stop filtering the filename in XWikiAttachment#setFilename
by Thomas Mortagne 19 Jun '12

19 Jun '12

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

4 4

[xwiki-devs] [Discussion] About hidden applications and how we find them
by Ecaterina Moraru (Valica) 18 Jun '12

18 Jun '12

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

4 4