Hello,
I am working on creating blog entries using xwiki. I was wondering if it would be possible to create a template for the blog entries so that they will be more structured?
Thank you for your time and help!
Hande Aksac
Hi,
Since I'm rewriting the new Rendering component
(see http://dev.xwiki.org/xwiki/bin/view/Design/NewRenderingArchitecture)
, we need to finalize the new syntax we want to have.
Right now I'v planned to use the same wiki syntax as now
(http://platform.xwiki.org/xwiki/bin/view/Main/
XWikiSyntax#HTextStyles) with only one change: all macros now need to
be closed.
For example: {macro}...{/macro} and {macro:text|param=value|.../}
Is that ok with everyone or do we want to make changes?
Thanks
-Vincent
Hi Devs,
I've been refactoring OfficeImporter code base to make it more modular and
maintainable. With these refactorings I believe we can improve the main
OfficeImporter API. Currently OfficeImporter component interface exposes
following two methods:
<code>
void importStream(InputStream documentStream, String documentFormat, String
targetWikiDocument, Map<String, String> params) throws
OfficeImporterException;
String importAttachment(String documentName, String attachmentName,
Map<String, String> params) throws OfficeImporterException;
</code>
Problems with these two methods are;
* Loosely typed (params)
* Both of them perform almost the same task.
There is also a problem with how customizations to the normal import process
is implemented.
So, I propose we deprecate these two methods and introduce following
methods:
<code>
XHTMLOfficeDocument officeToXHTML(byte[] officeFileData, String
referenceDocument, boolean filterStyles) throws OfficeImporterException;
XDOMOfficeDocument xhtmlToXDOM(XHTMLOfficeDocument xhtmlOfficeDocument)
throws OfficeImporterException;
XDOMOfficeDocument officeToXDOM(byte[] officeFileData, String
referenceDocument, boolean filterStyles) throws OfficeImporterException;
XDOMOfficeDocument buildPresentation(byte[] officeFileData) throws
OfficeImporterException;
Map<TargetPageDescriptor, XDOMOfficeDocument> splitXDOM(XDOMOfficeDocument
xdomOfficeDocument, int[] headingLevelsToSplit, String namingCriterionHint,
String baseDocumentName) throws OfficeImporterException;
</code>
As you can see, these methods are more granular and the responsibilities are
well defined. Customizing the import process can be done from the client
code. For an example:
1. Make the initial import from office to XHTMLOfficeDocument.
2. Perform customizations on the XHTMLOfficeDocument (w3c DOM).
3. Import the XHTMLOfficeDocument into XDOMOfficeDocument.
4. Perform customizations on the XDOMOfficeDocument (XDOM).
5. Split the XDOMOfficeDocument into multiple XDOMOfficeDocument instances.
6. Perform customizations on these child XDOMOfficeDocument instances.
7. Render the XDOMOfficeDocument instances & save them into wiki pages.
(saving can be done in client code)
I think this interface will make it easy to extend & maintain officeimporter
functionality in the future. For an example, a preview function can be
implemented with above methods (which is not possible with the previous
interface).
WDYT?
Here's my +1.
Thanks.
- Asiri
Hi, there,
I'm running the sanity check script on mysql 5.0.54 and there are some
queries return results. To correct these problems, should I simply just
delete these results or I need to do something else before the deletion?
Take an example, for the following query:
select * from xwikiproperties,xwikilargestrings where
xwp_classtype='com.xpn.xwiki.objects.StringListProperty' and
xwp_name=xwl_name and xwp_id=xwl_id
+---------+-----------------+--------------------------------------+---------+-----------------+---------------------------------------------
| XWP_ID | XWP_NAME | XWP_CLASSTYPE | XWL_ID | XWL_NAME | XWL_VALUE
+---------+-----------------+--------------------------------------+---------+-----------------+---------------------------------------------
| -1877168607 | subscribedDocuments |
com.xpn.xwiki.objects.StringListProperty | -1877168607 | subscribedDocuments
| Main.WebSearch|Main.Categories
| 261169163 | subscribedDocuments | com.xpn.xwiki.objects.StringListProperty
| 261169163 | subscribedDocuments | Service
Measurements.WebHome|IMProcess.WebHome
| 683557787 | subscribedWebs | com.xpn.xwiki.objects.StringListProperty |
683557787 | subscribedWebs | Replication
| 683557787 | subscribedDocuments | com.xpn.xwiki.objects.StringListProperty
| 683557787 | subscribedDocuments | IIS.WebHome
I've got couple hundred lines of records like this. If I delete all these
records, what kind of impact will be to my content?
Thank you very much for your help
--
View this message in context: http://n2.nabble.com/Help-About-Sanity-Check-tp3670302p3670302.html
Sent from the XWiki- Dev mailing list archive at Nabble.com.
Hi devs,
Since XE 2.0 will be released soon I'd like to release XE 1.9.4 and
XEM 1.7.4 tomorrow.
After this XEM release I suggest to create the 1.7 branch and make XEM
trunk 2.0.
Changelog since 1.9.3:
XWIKI-4249 . key acts like the delete key at the end of the list items
XWIKI-4263 Include macro should expose the default value of "context" property
XWIKI-4175 Livetable sorting failed when the text of the header column
is clicked
XWIKI-4093 Refactor the code to use the new EventHandler system
XWIKI-4158 Update the Feed Plugin to work properly with latest XWiki
and Rome Code
XWIKI-4170 Wrong encoding in ApplicationResources_pt.properties
XWIKI-4139 New {{formula}} macro for displaying mathematical expressions
Here's my +1.
JV.
Hello XWiki developers,
can someone explain me what is the strategy to define the mime-type of
an attachment?
I see not configurable map nor any setter on the attachment types.
Is there any way I can enrich this or is it simply taking over the
mime-type provided the browser (which, too often, ends up being
application/octet-stream) ?
thanks in advance
paul
Hi XWiki Devs & Users,
It's roadmap time again!
Based on the previous roadmap, feedback on the lists and the results of the
survey we conducted (see
http://www.xwiki.org/xwiki/bin/view/Blog/Features+Survey+Results ), here's a
list of stuff we might want to work on in the XE 2.1 timeframe which will
last approximately until December 2009:
IMPROVEMENTS
On top of the usual bugfix work, here's a list of improvements we might want
to bring in the course of the release in order to stabilize the 2. branch as
much as we can:
- Colibri skin
- Clean the skin so that it's no longer a pile of code added on top of
Toucan
- Improve the ColorTheme page (theme catalog, theme creation)
- WYSIWYG editor
- Test and improve IE8 compatibility
- Test and improve Chrome / Safari compatibility
- Add more translations
- Rendering
- Internationalize
- Add translations
- Conversion to 2.0 syntax
- XAR 2.0 (notably Blog & Panels)
- Office importer
- The application shouldn't be displayed when the office server is not
running
- Wiki macros
- Textarea should be larger
- Importer
- Make the import create new versions of existing pages instead of
overwriting them
- *Search (one of the most asked for features in the survey)*
- Fix the bugs with our Lucene Search implementation to make it the
default one
- Finish implementing the new search UI
- Performance (one of the most asked for features in the survey)
- Clean and apply Denis Gervalle's patch related to attachment upload
memory handling
- Clean and apply Caleb James DeLisle's patch related to document
loading
- Keep working on making the skin lighter
- Other?
- User Profile UI
- Improve the watchlist UI
- Make the user profile look clearer
NEW FEATURES
We won't have the time to work on all of them, but here's a list of new
features we might want to consider working on:
- Skin -> revamp / move the action bar
- CAPTCHA Integration -> make CAPTCHAS available on login / comments
- Application Manager -> create applications descriptors, ability to
version applications
- Document Type Manager -> make XClass & application creation easy
through a nicer UI
- Invitation Manager -> make it easier to add users to the wiki (send an
email allowing account creation)
- Multipage Management tools -> create and export lists of pages
Feedback is welcome and appreciated.
Thanks,
Guillaume
--
Guillaume Lerouge
Product Manager - XWiki
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
Hi all,
I propose we create a user on XWiki.org that will subscribe to daily
watchlist notifications on the xwiki.org wikis, with
notifications(a)xwiki.org as email address.
We can try to watch entire wikis, though we might get some noise on
certain wikis (for example with all users that are created on the main
wiki).
WDYT ?
+1 to try out this.
Jerome.