Hi Vincent,
I try to make the xhtmlparser work for the link. I have see the test
case links.test in xwiki-core-rendering.
I have some questions.
1) the xhtmlparser don't handle the rel attribute. Because wikimodel
don't pass the information in xhtmlparser. see
http://code.google.com/p/wikimodel/issues/detail?id=47. When this is
fixed, I think rel can works.
2) The output of <a href="mailto:john@doe.com">mailto:john@doe.com</a>
should be [[mailto:john@doe.com>mailto:john@doe.com]] but not
[[mailto:john@doe.com]]. We should not remove the label information of
mailto. Consider if the input is <a href="mailto:john@doe.com">Contact
me</a>, the output should be [[mailto:john@doe.com>Contact me]]
--
Thanks
Wang Ning
Hi,
I'd like to discuss the granularity we want to have for our
applications. This discussion was prompted by the recent password-
reset application. There are some pros and cons I think of having
small applications.
Pros:
- better compartimentation
- different release cycle
Cons:
- heaviness of release (separate XAR; etc)
- different release cycle
- fragmentation
My personal take is that this application should go under the
administration application so that it's released together with it (it
could be a sub module that is aggregated in the final XAR for the
admin app.).
WDYT?
Thanks
-Vincent
The new JDBC driver for postgresql 8.3.3 supports set/getcatalog()
now. Does that mean we can finaly use it with virtual xwiki ?
cheers
Michal
Michal Bielicki, COSO, Member of the Board
HaloKwadrat | ul. Polna 46/14, 00-644 Warszawa
t. +48228753290 x 203 | f. +48228753291
michal.bielicki(a)halokwadrat.pl | w. www.halokwadrat.pl
Knowledge & Low Prices. Guaranteed!
Halo Kwadrat Sp. z o.o.
z siedzibÄ… w Warszawie przy ulicy Polnej 46/14,00-644 Warszawa
wpisana została do rejestru przedsiębiorców prowadzonego przez
Sąd Rejonowy dla M.ST.Warszawy w Warszawie, XII Wydział Krajowego
Rejestru SÄ…dowego pod numerem
KRS 0000153539. NIP 525-22-59-473
Wysokość kapitału zakładowego: 50000,00 PLN
----------------------------------------------------------------------------
Wiadomość ta jest przeznaczona jedynie dla osoby lub podmiotu
będącego jej adresatem
i może zawierać poufne lub uprzywilejowane informacje. Zabronione
jest przeglÄ…danie,
przesyłanie, rozpowszechnianie lub inne wykorzystywanie tych
informacji, jak również
podejmowanie działań na ich podstawie, przez osoby lub podmioty inne
niż zamierzony adresat.
Jeżeli otrzymali Państwo tę wiadomość przez pomyłkę, prosimy o
poinformowanie o tym nadawcy
i usunięcie jej z komputera.
Hi Vincent,
When I implement the XWikiDocumentConvertOutput, I meet some pb. I
understood that the XWikiDocumentConvertOutput contain a xwiki
document, and it will store the result html to the xwikidocument as
content, store the images to the xwikidocument as the attachments, and
save this xwiki document to the xwiki.
But we should separate the officeconverter from xwiki core, so
XWikiDocumentConvertOutput can't get any information about xwiki
contex, right?
Problems with this design:
1) when I use the saveDocument() method to save the inputstream to
document content, I need convert inputstream to html. But I can't get
the encoding of the xwiki because I can't access the xwiki context.
2) I can't set the attachments' author, because have no idea about the
author without context.
3) I can't save the xwikidocument to the xwiki without the xwiki context.
4) Maybe we can just save everything in the xwiki document and get it
from ConverterOutput and set author, then save it to the xwiki. If so,
we need a method getDocument() in ConverterOutput to get the document.
5) Actually, not all the accessory output is image. So the saveImage
interface is not appropriate.
Why we use ConverterOutput? I think because:
1) the output of conversion(especially convert to html) have no only
one output, so we just use ConverterOutput to save all this outputs
and their names for later use.
2) Maybe the special ConverterOutput like XWikiDocumentConvertOutput
can handle the coversion result to the special destination in special
format.
I think 2) is not right, because it make the office convert connected
to xwiki context.
So I proposal ConverterOutput is just a data structure to store the
output results and their name. My proposal is:
public interface ConverterOutput
{
/**
* Save the target contents in {@link InputStream} to the output
destination. And save the document's name as the
* main output file's name.
*
* @param documentName the name of the source content
* @param documentData the source data
*/
void saveDocument(String documentName, InputStream documentData);
/**
* Save the other output files like images, other htmls to the
output destination. In most case, this method will be
* used when convert office convert to html.
*
* @param accessoryName the accessory name
* @param accessoryData the accessory content
*/
void saveAccessory(String accessoryName, InputStream accessoryData);
/**
* @return the main document
*/
InputStream getDocument();
/**
* @return return the main document's name
*/
String getDocumentName();
/**
* @return the accessories of this document. The map's key is the
accessory's name.
*/
Map<String, InputStream> getAccessories();
}
I implement the office converter with this interface. Please review
the code at your convenience.
--
Thanks
Wang Ning
Hi Vincent & devs,
You are busy for 1.6M1 today, so you can handle this email later at
your convenience.
To provide something can work for gsoc, I take the convert2html
feature back with a little change about the filter. So the
officeconverter core + officeconvert plugin + office import appliation
can do:
1. import office document like doc, xls, ppt, odt, odp, ods to xwiki
page in html format. This feature works well in most case. Just try
it. It handles the images, the slides in ppt odp.
2. import office documents to xwiki page in xwiki syntax 2.0 format.
This feature is relative to xhtmlparser in new rendering. So it can
only work for some case. table, link, image, list are not supported
well.
I think this can be called some thing works in some extent.
--
Thanks
Wang Ning
Hi,
We're a bit late on the planning/roadmap so here's a first try.
* 1.6M1: 18 Aug
* 1.6M2: 8 Sep
* 1.6RC1: 15 sep
* 1.6RC2 or 1.6 final: 22 sep
Tentative Roadmap for XE 1.6:
Must have:
========
* Beta versions of new rendering + new WYSIWYG editor (Vincent & Marius)
* One of the following two:
** Revamped Blog UI + features (who?)
** Easy creating of structured pages (JV)
* Security issues already in JIRA (marked as high priority)
+ bug fixes or course
Good to have
==========
* Office import maybe but I think that should be optional depending on
how fast it progresses. It could be released as a separate plugin for
sure.
* Single sign on w/ openID
* French XE
* Send forgotten password
* Improved RSS feeds
* Excel plugin
* Installation wizard
* Skin extension/Interface extension finalization
* CSS + templates cleanup/simplification
* Invitation manager in XE
My personal take is that the core development team should really focus
on the "Must Have" and continue consolidating what we have by working
on make it more stable, nicer looking and more usable, rather than
working on new features. Of course we have all those nice SOC projects
(office import, sso) that we should release/integrate if they are
ready at the end of the milestone 2 of XE 1.6.
WDYT?
Thanks
-Vincent
Hi!
I am looking for some information on the supportablitlty of Xwiki with
SSO for authentication. At this stage, I am exploring the options on
how to set this configuration up. There is not much documentation
available on the Xwiki site on information for integrating with SSO
siteminder though a reference to siteminder is available on the site(
http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Authentication check
under Custom Aunthentication). I was wondering if any of you could
direct me towards more resources/documentation...
Thanks.
Sharan.
-----------------------------------------
This communication is for informational purposes only. It is not
intended as an offer or solicitation for the purchase or sale of
any financial instrument or as an official confirmation of any
transaction. All market prices, data and other information are not
warranted as to completeness or accuracy and are subject to change
without notice. Any comments or statements made herein do not
necessarily reflect those of JPMorgan Chase & Co., its subsidiaries
and affiliates.
This transmission may contain information that is privileged,
confidential, legally privileged, and/or exempt from disclosure
under applicable law. If you are not the intended recipient, you
are hereby notified that any disclosure, copying, distribution, or
use of the information contained herein (including any reliance
thereon) is STRICTLY PROHIBITED. Although this transmission and any
attachments are believed to be free of any virus or other defect
that might affect any computer system into which it is received and
opened, it is the responsibility of the recipient to ensure that it
is virus free and no responsibility is accepted by JPMorgan Chase &
Co., its subsidiaries and affiliates, as applicable, for any loss
or damage arising in any way from its use. If you received this
transmission in error, please immediately contact the sender and
destroy the material in its entirety, whether in electronic or hard
copy format. Thank you.
Please refer to http://www.jpmorgan.com/pages/disclosures for
disclosures relating to UK legal entities.
Hi,
Here's a proposal for implementing configuration in the new
architecture, using components.
Note: I think this is compatible with Sergiu's proposal here: http://tinyurl.com/6md5jd
General requirements
=================
* Each module/component can define its own configuration
* Accessing configuration parameters from Java should be strongly
typed (ie. getLinkLabelFormat() for getting the link label and not
getParameter("linklabelformat"))
* It should be possible to load Configuration data from different
sources (properties file, xml files, database, xwiki documents, etc)
* Configuration sources should have an order
* Any module/component should be able to get the configuration for
other module/component but in read only mode
* It should be possible to dynamically add a new configuration source
at runtime
* Configuration data should be loaded and cached
Proposed Implementation
====================
* Each module/component defines its configuration in a component which
is a java beans. For example let's take the rendering module. We would
have a RenderingConfiguration component as in:
public interface RenderingConfiguration
{
String getLinkLabelFormat();
}
public class DefaultRenderingConfiguration implements Initializable,
Reloadable, RenderingConfiguration
(in practice will extend AbstractConfiguration class probably)
{
private String linkLabelFormat;
// Injected
private ConfigurationManager manager;
public void initialize()
{
// Define the Configuration sources here. Default
configuration sources would be defined in AbstractConfiguration
probably)
List configurationSources = ....
// Configuration namespace (all properties should start with
the namespace value)
String namespace = "rendering";
reload();
}
// Should be located in AbstractConfiguration
public void addConfigurationSource(ConfigurationSource source);
public void reload()
{
// Populate java bean
manager.populate(this, configurationSources, namespace);
}
public void setLinkLabelFormat(String linkLabelFormat) {...}
public String getLinkLabelFormat() {...}
}
* The DefaultRenderingConfiguration class is registered as a component
in components.xml and with a singleton lifecycle. This means the data
it contains are cached for the whole application lifetime. They can be
reloaded using reload().
* The ConfigurationManager implementation will use Jakarta BeanUtils
to automatically populate a javabeans. It'll also use Jakarta Commons
Configuration for implementations of ConfigurationSource.
* ConfigurationSource interface should have a method like: Object
getParameter(String name). More details to be defined later.
* Code wanting to get Rendering Configuration would simply define a
component dependency on DefaultRenderingConfiguration and they'll have
it injected for them.
* There'll be a XWikiDocumentConfigurationSource that gets parameter
values from one or several xwiki documents. We'll need to define how
we get them but we could provide some standard XWikiConfigurationClass
for a single configuration element for example.
* The idea of the namespace is to use the package name and remove the
"org.xwiki" or "com.xpn.xwiki" prefix. For example
"org.xwiki.rendering.*" leads to "rendering.*".
WDYT?
If we agree I can whip up a first implementation of this relatively
quickly I think.
Thanks
-Vincent