xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

by Jonathan Solichin

Hi Jerome & Community, Here is the design page for the Responsive Skin [1]. * I'd like we start with a phase of "paper" design (I mean with gimp > or photoshop or whatever tool to produce images). This is available in the design page, or, alternatively phone [2], tablet [3], desktop [4] * I think we should limit the feature set of the skin ; not trying to > do everything right away (there are potentially a lot of features to > work on, from livetables to data editors, to applications, etc.) * For a start, focus should be given on content and navigation. With a > mobile-first approach, expanding up to large-screens desktop. * I think it's OK to have semantic break points (like "phone", > "tablet", etc.) as long as the skin is actually responsive and adapt > to whatever real estate is available. We should be able to "drag the > corner" of a browser window and have the skin display well at all > sizes. Agreed. Also, current questions (c&p) from other e-mail regarding gsoc: 1. Specific support for non-javascript capable browser? I feel like it is not necessarily since browser which can not support javascript will fall back by itself. More over, it would not be capable of carrying out media-queries required for responsive design and some XWIKI features (such as live tables?) anyway. 2. Is the community ok with trying to use "true (html)" drop downs / forms in order to fully utilize functions built in to phone/tablets [5]? 3. Pressable Links: should they be bigger on mobile to help facilitate touching on words, or would it be better to use a "background" to create a "touch area"? Both are in the phone mock up [6]. Former demonstrated in quicklinks, latter in the "Spaces" section. [1] http://dev.xwiki.org/xwiki/bin/view/Design/ResponsiveSkin [2] http://jssolichin.com/public/mobile.jpg [3] http://jssolichin.com/public/tablet.jpg [4] http://jssolichin.com/public/desktop.jpg [5] http://css-tricks.com/convert-menu-to-dropdown/ [6] http://jssolichin.com/public/mobile.jpg

12 years, 7 months

[xwiki-devs] [GSoc] XDroid Platform

by sasinda rukshan

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) |-- 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. [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. Thank you Best Regards. Sasinda Rukshan

12 years, 7 months

[xwiki-devs] Choosing the default component implementation [take 2]

by Sergiu Dumitriu

Hi devs, Hmm, time flies, I realized that it's been a month and a half since I started this thread, but didn't get to counter-argument so far. Because I wanted to give more compelling reasons after I wrote the initial draft of the original proposal, I got slammed with counter arguments centering mostly on why our current implementation already allows to work around the technical difficulties that I presented, although those technical difficulties were just extra arguments that weren't actually that important. Let's start from scratch. I believe that using "default" as a component hint is in most cases wrong, since it doesn't actually say anything about the particular implementation. Let's take some examples: EntityReferenceSerializer, with its many implementations: - "compact", which creates compact representations that don't repeat the parts that are the same as the current document - "compactwiki" that only skips the wiki part when not needed - "path" which creates references usable as a path on the filesystem or in URLs - "uid" which creates non-ambiguous representations - and "default", which does a... default representation... whatever that means... So, while the meaning of the other hints can be guessed from their name, that's not true for "default". WikiModel, with its only implementation, XWikiWikiModel, labeled as "default". First, this "default" is defined in xwiki-platform instead of xwiki-rendering, like the components that actually use that component, which means that we're defining a component interface without any implementation in our "standalone rendering engine", and thus we're using "exceptions as normal decision code" which is wrong. Second, this "default" actually means "xwiki default". Why can't the hint be "xwiki" instead of "default", since that what that implementation is actually doing: "this is the model used in XWiki", and not "this is the default model that most wiki engines use". When looking up an instance of the WikiModel component, we don't request "the default wiki model", but "the wiki model currently in use, whichever that is". ConfigurationSource and its implementations: - "space" which looks into space preferences - "wiki" which looks into wiki preferences - "user" which looks at user preferences - "xwikiproperties" which looks in xwiki.properties - "all" which looks into all the above - "void" which is always empty - "memory" which stores settings explicitly set by code - and "default" which does... stuff... let me get back at you after I look into its code to check what it actually does. XHTMLLinkTypeRenderer is an example where "default" does make sense, since we have special treatment for "doc"ument, "attach"ment, "mailto", "unc", "interwiki", and then there's a "default" that handles all the others, like "url" and "path". I was writing a component called UploadedFileManager, which is supposed to parse uploaded files from a request, and the implementation for it was called CommonsFileUploadManager, since it used the Apache commons-fileupload library for the actual request parsing. I don't think that calling it "default" is appropriate, since in the 3.0 servlet specification the upload behavior is embedded in the specification, in the ServletRequest interface, and that seems more "default" than using a particular library to do the job. A more appropriate hint is "commons", since that's what it actually does: "this implementation handles file uploads by using the apache commons library that does that", and not "this implementation handles file upload in the default way, which everyone should know what it actually is". So, I strongly feel that what the component manager returns when looking up a component without a hint shouldn't be the implementation labeled "default", but one of the existing implementations, as configured somehow. I'm not yet sure how that configuration takes place, that would be the subject of another discussion, but I'd like to get a consensus on whether we need this change or not. -- Sergiu Dumitriu http://purl.org/net/sergiu/

12 years, 7 months

[xwiki-devs] [VOTE] Add right related method to the wikimacro/oldcore bridge

by Thomas Mortagne

Hi devs, Despite what the documentation is saying anyone can register a wiki macro for the whole wiki so I'm about to fix it. See http://jira.xwiki.org/browse/XWIKI-7880. But to fix it properly IMO I need to add a right checking method to the wikimacro/oldcore own bridge. Right now the right check is a pile of hacks using various APIs (WikiModel for edit, DocumentAccessBridge for programming) and there is no way to test admin right in existing bridges and APIs anyway. Instead of adding more hacks to the current wiki macro right checking I find it better to move the check itself to its existing own model bridge and test it there using the rightservice directly. It also make more sense to have this check at the wiki macro model bridge level than the wiki macro component itself. This is a pretty hidden API that noone is supposed to use except the wiki macro and oldcore but since it's a public interface it makes CLIRR complains so according to our rule here is the vote for adding this new method. WDYT ? Here is my +1. Since the master is now on 4.2 branch I'm committing it right now. Will revert it if anyone gives a veto. -- Thomas Mortagne

12 years, 7 months

[xwiki-devs] [GSoC] [SOLR]: search and XWiki rights

by Paul Libbrecht

Dear Savitha, Dear XWiki community, that I know of, there's two major flaws in the current lucene plugin: - It stores and indexes everything which makes it a big memory eater. This will be fixed by Savitha using Solr's schema.xml and hopefully other admin-configurred classes. - Each of the search results' list has to be skimmed through so that the count only covers documents one has access to (this is done in SearchResults.java in getRelevantResults). This has the direct consequence that a search for all documents basically goes through all documents which is quite annoying. In general, the practice of going through many documents, one could say the practice of pre-processing the search-results' list, is a catastrophe. There are very many times when a user inputs a query that matches way too many documents. That means also that Savitha should avoid this skimming in her SOLR module and this needs some skills and probably some help: - the skills to understand completely the rights model. As far as I know it is based on XWikiRights objects in each document and can talk about users (a list of users) and groups. but this needs to be deeply observed and asked many times about. - the skills to map this model into something that is executable by Solr/Lucene queries. In Curriki or i2geo and in many other specific applications, this is much easier because the rights model is simpler (owner is defined, only three rights possible). But this has to be done in a generic way and might include the requirement to reindex a large part of documents if a user joins or leaves a group. I am thinking this can be implemented: include fields such as "prohibitedFor" "prohibitedForGroup", "allowedFor", "allowedForGroup" and use the current users' identity and groups when querying. I note that it is important to care for the user that requests the documents when indexing as well (which probably needs to be admin). Savitha, I think this is the hardest part of your project. Are you up to it? paul

12 years, 7 months

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

by Jonathan Solichin

Hello friends, So here is a clearer illustration of what I am aiming for: http://sdrv.ms/LO70JI The font being used in these design is Arial (with changes to make it more unique). I was wondering whether the community would like a more regular looking font, or a bolder and unique one? I would be glad to hear the community's feedback. I tried to bring into account all the comments, but let me know if I missed something. Thanks again, Jonathan Solichin p,s almost done with school (one week), will be able to push faster and better soon. Sorry about that!

12 years, 7 months

[xwiki-devs] [UX] [Iteration] Improve History Diff

by Ecaterina Moraru (Valica)

Hi, As you know Thomas and Marius are working on a Diff API and there are also some conflict resolution improvements for the Extension Manager [1]. Marius asked me to think about our current history diff and make some improvements suggestions based on their work. I've made a mockup with some ideas that could improve the History Diff UI http://incubator.myxwiki.org/xwiki/bin/view/Improvements/DiffHistory The UI is mostly based and inspired from GitHub. Let me know what you think. Thanks, Caty [1] http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWikiEnterpris…

12 years, 7 months

[xwiki-devs] [VOTE] Merge feature-diff-display branch into commons master

by Marius Dumitru Florea

Hi devs, The feature-diff-display branch provides a new diff module, xwiki-commons-diff-display, with APIs to help displaying diffs. Currently it supports two diff formats: unified (GitHub style, suited for code) and inline (suited for free text). I'm using this module for the merge conflict resolution UI and for an improved document compare UI (when comparing two versions from a document history). I'd like to merge the branch ASAP, before 4.1RC1 is released. Here's my +1. Thanks, Marius

12 years, 7 months

[xwiki-devs] [WARNING] Release 2 days away, branching now, reply here if you need to commit to the release branch.

by Caleb James DeLisle

Hi, I'm going to be starting the stable-4.1.x please tell me if you need to commit against this branch I would like to know what's going to be committed into this branch so we can hopefully avoid the: "late commits - destabilize the build - delaying the release - allowing more late commits" cycle. Of course I also need to know if anyone needs to hold up the release. Thanks, Caleb

12 years, 7 months

[xwiki-devs] [Prooposal] Roadmap for XE 4.1

by Vincent Massol

Hi devs, Roadmap time again for 4.1. Here's a proposal below. If you're a committer/contributor and wish to propose doing something for 4.1 please reply to this thread to have a complete roadmap. For committers who have their names next to tasks below, please confirm you're ok to do that for 4.1. Dates ====== * Started since 16th of April * 4.1M1: 7th of May * 4.1M2: 28th of May * 4.1RC1: 11th of June * 4.1Final: 18th of June Release manager: Caleb, with help from Sergiu/Vincent Content ======= XWiki SAS has had an internal meeting to discuss what it would like to work on and here's the result as a proposal: Top level tasks: * Extension Manager (XEM compatibility, XAR merge UI, full XAR upgrade) - Thomas and Marius ** The goal is to be able to "upgrade a wiki farm in 5 minutes" for 4.1 final * Hidding Technical Content - Jean-Vincent * Important JIRA issues - Sergiu and anyone having some time, see below for the priority list Investigations: * Home Page Changes Proposals - Caty Misc: * GSOC mentoring - All mentors First priority JIRAs (no order): * Add the ability to auto-generate application entry names XWIKI-7374 * Properly display live table columns based on User-type class fields XWIKI-7372 * Be able to rename a space from the UI XWIKI-6722 Second priority JIRAs (no order): * Add Required and Hint meta properties for class fields XWiki-7373 * Generate and register a document bundle for the application XWIKI-7371 * Add document title and document content to the field palette (class editor) XWIKI--7369 * Use suggest input (custom display) for User and Group field types (class editor) XWIKI-7368 * Rename Application (through rename space) XWIKI-6722 * OpenOffice Issues on Windows (bug) XWIKI-7510 * Cannot filter using "/" on a Date column in the livetable XWIKI-5889 * Auto-create Space.WebHome when creating a page in an underfined space XWIKI-5399 * New XWiki Syntax Guide XE-880 * Occasionally the livetable fails to load on index pages XE-844 * tag suggest feature does not work if Main.WebHome is not saved with programming rights XE-539 * Fix XWiki Installer on Windows 7 XE-1051 * XWIKI-6073 Change stylesheet and javascript extension filename when a modification is done on those Unassigned Third priority (no order): * Add more/all configuration parameters in the wiki administration XWIKI-7066 * XWIKI-7510 XWiki is not able to automatically start OpenOffice daemon on Windows Server Unassigned * XWIKI-7509 XWiki automatically connect to an external openoffice daemon Unassigned * XWIKI-7058 Page creation date should be the date of the installation Unassigned * XWIKI-6951 When using filesystem attachments with attachment versioning disabled, deleted attachments are duplicated on the hard disk. CalebJamesDeLisle * XWIKI-6917 Deleted attachments duplication in recycle bin while File Storage is on CalebJamesDeLisle * XWIKI-6892 Log-in automatically on registration Unassigned * XWIKI-6569 Problems displaying the correct attachment version when using a proxy Unassigned * XWIKI-6363 Performance of blog category panel is still not enough Unassigned * XWIKI-6207 Auto-suggest doesn't work for global users Unassigned * XWIKI-5949 Better handling of different timezones for date properties Jean-Vincent Drean * XWIKI-5930 Activity Stream doesn't show Image Profile change Unassigned * XE-1031 Better placement of the documentation link Unassigned * XE-748 Add option to 'show more entries' on displaying the Activity Stream Unassigned WDYT? Thanks -Vincent

12 years, 7 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs