Hi devs,
I had started a first VOTE:
http://markmail.org/thread/56v5thsj6wv7tpno
But since that first VOTE transformed into a brainstorming I'm starting a new VOTE below with the result of our brainstorming:
* Distribute without legacy modules by default
* Document how users can add legacy modules and make that visible from the download page somewhere.
* Move deprecated APIs to legacy modules as soon as our code is clean and stops using the newly deprecated APIs
* Never remove APIs from the legacy modules by default but when we really need to do so (for some technical reason for example), do it on a case by case basis and send a VOTE to do so
This ensures that:
* New users quickly use the newest APIs (they won't even see the old APIs by default).
* Older users are not broken since they can add the legacy modules
* When someone upgrades he can easily try using the new distribution without legacy and if it breaks some of his code he can either fix his code or add the legacy modules
Here's my +1
Thanks
-Vincent
Hi,
I've been working a while ago on a Mobile Skin which principle is the
following:
1/ Light UI adapted to mobile devices, both phones and tablet (with a
particular attention to tablets), giving most of the screen real estate to
the page content
2/ Support all Javascript normally supported in the XWiki skin in order for
any code inside pages that would use this Javascript to still work
3/ Automatic detection of mobile devices to make them switch to the mobile
skin
4/ Ability to switch from mobile to normal skin
5/ compatibility with color themes
I believe this approach is the right one, as XWiki instances do have
significant Javascript and in order to make sure these pages work, we need
to be able to accept this javascript.
Of course some other improvements could be done, for example to have a
mobile friendly dashboard or livetable.
Now this work has had a few iterations with particularly some relooking
work from Caty.
The work is published here:
http://extensions.xwiki.org/xwiki/bin/view/Extension/SimpleMobileSkin
And the code is available here in both XAR and File-System version (for
XEM):
https://github.com/ldubost/xwiki-mobileskin
The skin can be tested on the incubator (although there is not the
automated switch)
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/34Proposal?skin=XW…
I've also worked on integrating this in the platform. The commit is
available in a fork on github:
https://github.com/ldubost/xwiki-platform/commit/064baeb017b35e08a526029381…
I'd like some comments and discussion so that we can bring this into the
platform.
Ludovic
--
Ludovic Dubost
Founder and CEO
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
Hi devs,
For the upcoming Application Within Minutes I need to enhance the
XWiki platform with the ability to generate the page name
automatically when creating a new wiki page. For some applications it
doesn't make sense to have two creation steps: (1) specify the wiki
page name (i.e. the location) and then (2) edit the new wiki page with
the specified name. Let me give you two examples:
* It would be cool to be able to create a new blog post in a single
step. The blog post name could be generated from the blog post title
specified in the edit form.
* An application that manages holiday requests doesn't need meaningful
page names (i.e. free text, like a blog post would have) but something
like Request_XYZ, where XYZ is a unique counter/identifier.
These applications should be able to create new wiki pages with
automatically generated names without writing their custom create
forms.
Since 3.2RC1 was planed for today and these changes are in the 3.2
roadmap, here's a proposal that I think I can implement quickly and
safely:
(1) Introduce two new components:
// Used to generate a document name that doesn't have to be unique
(e.g. by cleaning the document title).
DocumentReferenceGenerator#generate(DocumentModelBridge):DocumentReference
// Used to make a document name unique (by suffixing an unique
counter/identifier)
DocumentReferenceDifferentiator#differentiate(DocumentReference):DocumentReference
(2) Modify editinline.vm to store "documentReferenceGenerator" and
"documentReferenceDifferentiator" request parameters in two hidden
input fields so that they are passed to the save action. Obviously,
these are component hints.
(3) Modify editactions.vm to replace "Save & View" + "Save & Continue"
with "Create" when "documentReferenceGenerator" or
"documentReferenceDifferentiator" (or both) request parameters are
set.
(4) Modify SaveAction to take into account these two request
parameters (only if they are specified). Something along these lines:
generateDocumentReference(doc)
synchronize(lock) {
doc.copyDocument(differentiate(generatedDocumentReference)).save();
}
I'm not sure where to place the two components from (1) though. WDYT?
Thanks,
Marius
Hello,
In velocity I was using :
$services.rendering.parse(...)
$services.rendering.render(...)
My question is : how can I inject the component to do that from a java
component, specifying the parser/syntax ?
I just had a quick look to the tests but they use the componentManager while
I preferred to use annotations until now, so I'm a bit lost ... :)
Thanks
Jeremie
--
View this message in context: http://xwiki.475771.n2.nabble.com/How-to-call-rendering-component-tp7487904…
Sent from the XWiki- Dev mailing list archive at Nabble.com.
Hi, all,
I logged in as an administrator, I like to create a new page under jQuery
with this URL:
http://mydomain/xwikim/bin/create/jQuery/WebHome
when I click the Create button, it always redirected me to localhost as
following:
http://localhost/xwikim/bin/edit/jQuery/jQueryUICustom?template=&parent=jQu…
which caused error message: Unable to connect, I tried to create from Main
space, also the same problem and redirected me to:
http://localhost/xwikim/bin/edit/Main/jQueryUICustom?template=&parent=Main.…
when this happens, I have to replace the localhost with mydomain on browser
address and press enter to bring up the page, this happened to me many
times when I need to do edit action, when it is view action, it works
perfectly, I have httpd apache webserver in front of tomcat, in apache
config file, my setup is:
ProxyPass /xwikim http://localhost:8082/xwikim
ProxyPassReverse /xwikim http://localhost:8082/xwikim
In tomcat server.xml file, the setup is:
<Connector port="*8082*" maxThreads="*150*"
minSpareThreads="*25*"maxSpareThreads
="*75*" enableLookups="*false*" acceptCount="*100*" connectionTimeout="*
20000*" proxyPort="*80*" disableUploadTimeout="*true*" />
I feel this setup should be ok, since it works all the time except
sometimes it does not work for edit action or login.
Does anybody have ideas about what happened and how to fix?
Thanks very much in advance.
Dave
Hi dev,
To get a proper setup of installed extensions we want to make sure
everything is installed trough Extension Manager instead of being
imported as a plain xar. So the idea come up to finally start the long
awaited installer/upgrader UI.
First step is to find how to know when to display this UI so here is a
proposal (ref http://dev.xwiki.org/xwiki/bin/view/Design/Installerandupgrader):
= The new informations
* deprecate version.properties for a more complete
distribution.properties that would contains at least the following
** version of the distribution
** top extension id of the distribution (to display general
informations about the distribution). For example in XE it would be
distribution.id=xwiki-enterprise
** name of the distribution (I'm not 100% sure for this one since we
can find it with the id using Extension Manager but I think it's safer
in case we don't have access to any repository to display something
nicer than a technical id). For example for XE it would be
distribution.name=XWiki Enterprise (who would have guessed :)).
** war extension id of the distribution (generate a default id like
<product-id>-web when none is provided). For example in XE it would be
distribution.web.id=xwiki-enterprise-web
** ui extension id of the distribution (generate a default id like
<product-id>-ui when none is provided). For example in XE it would be
distribution.ui.id=xwiki-enterprise-ui
** then come custom properties specific to the distribution. For
example in XE I think we could add commons.version, rendering.version,
etc.
= The current informations
* store all that in a table of the DB to compare the current with what
comes with the war. If the DB does not contain anything its a new
install, if the DB contain something different it's an upgrade (note
that this also support downgrade or moving from one distribution to
another like XE -> XEM the same way). The idea is that we store theses
informations only when the installer/upgrader is fully passed or that
the user explicitly indicated tat he does not want to install or
upgrade anything so that if you only did part of it before restoring
you can come back and continue the install/upgrade process.
= The manager
* introduce a xwiki-platform-distribution to manipulate all that
= Some questions
1) "distribution" or "product" ?
2) reuse the same table where we currently store the DB version ?
I don't want to talk about the installed/upgrader UI itself for now,
it will be the subject of another mail. I would like to concentrate of
one step at a time since that's going to be pretty important system.
WDYT ?
The may goal that started this proposal is the installer/upgrader UI
but those as also very useful for different use case. Some lib could
want to know the version of platform or commons to choose what to do,
we will be able to add the id of the distribution itself and the war
extension as core extension to allow some extension to put it as
dependency, we will finally display a proper footer without putting
the distribution name in the XWikiPreferences.
Here is my +1.
1) my +1 goes to "distribution"
2) my +1 goes to another table to not mix different subjects
Thanks,
--
Thomas Mortagne
I use the xwiki 3.5.When I edit a long text(longer than one screen) with
the wysiwyg, Every time I press t he enter button or insert a heading,it
will jump t.o the head of the page which I am editing.Is there any solution
to it or it is just a problem only I met
I tried to use wiki="false", or remove //<![CDATA[ and //]]>, still the
event callback function never get called, any other reason?
Thanks for your response, please help.
Dave
On Wed, Apr 18, 2012 at 5:33 AM, Marius Dumitru Florea <
mariusdumitru.florea(a)xwiki.com> wrote:
> Hi Dave,
>
> On Wed, Apr 18, 2012 at 6:43 AM, du du <dddu88(a)gmail.com> wrote:
> > Hi all,
> >
> > I have the following velocity code in xwiki page, I can see the fid and
> > fname values when I retrieve entryobj from the server side, so I want to
> > use javascript to add the fid and fname to image link node as parameters
> of
> > the href url. the problem is the javascript loaded event function never
> got
> > called, why?
> >
> > Thanks very much.
> >
> > Dave
> >
> > {{velocity filter="none"}}
> > {{html clean="false" wiki="true"}}
> > <script type="text/javascript">
>
> > //<![CDATA[
>
> wiki="true" causes // to generate an EM HTML tag. Just look at the
> page HTML source (all browsers have this option) and you'll see that
> your SCRIPT tag is messed up.
>
> My advice is to:
>
> * use a JavaScript extension (
>
> http://platform.xwiki.org/xwiki/bin/view/DevGuide/SkinExtensionsTutorial#HM…
> ) instead of in-line SCRIPT tag
> * try to avoid HTML macro with wiki="true" or, if it's not possible,
> try to reduce as much as possible its content, i.e. wrap only the code
> that really needs it.
>
> Hope this helps,
> Marius
>
> > document.observe("xwiki:dom:loaded", function(){
> > var imageNode = document.getElementById('tmViewImages');
> > var url = imageNode.href;
> > var index = url.indexOf("?");
> > if(index!=-1)
> > url = url.substring(0,index-1);
> > url=url+"?FID=$!fid&FName=$!fname";
> > imageNode.href=url;
> >
> > //]]>
> > </script>
> >
> > #getEntryItemObject($doc $entryObj)
> >
> > #if("$!entryObj" == '')
> > #warning($msg.get('xe.blog.sheet.notpost'))
> > ## Keep testing the inline action for backward compatibility with older
> > blog posts.
> > #elseif($xcontext.action != 'edit' && $xcontext.action != 'inline')
> > ## View mode
> >
> > #set($fid=$entryObj.getProperty('FID').value)
> > #set($fname=$entryObj.getProperty('FName').value)
> > fid view: $fid
> > fname view: $fname
> > _______________________________________________
> > devs mailing list
> > devs(a)xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
> _______________________________________________
> users mailing list
> users(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/users
>
Hi all,
Developping the mail archive, I realize that this app (that will consist of
extension .xar + component .jar) will have many dependencies on other
extensions.
To cite only some, there will be : mktree, tabs, livetable export to excel,
ratings, ...
When possible I try to make these dependencies optional : if you want the
related feature, install the extension and check the option (for ex.
livetable export to excel). But some dependencies will be mandatory anyway.
To prepare things correctly in advance, what is the best approach in this
case ?
Do I only need to list the dependencies, and prevent users that to install
my app, they need to install the other extensions as prerequisites ?
Can it be managed automatically by the extension manager during install of
my app (it would install the others before) ?
Or should I package all these inside my own app for sake of simplicity ?
(but it's ugly)
Thanks,
Jeremie
--
View this message in context: http://xwiki.475771.n2.nabble.com/Approach-for-extensions-with-multiple-dep…
Sent from the XWiki- Dev mailing list archive at Nabble.com.