Hi Devs,
ComponentManager interface at the moment doesn't use generics and we have to
manually cast the results into corresponding types. But with new notion of
using Class objects for roles (for lookup) I think it would be very easier
to generify this interface.
Here is my +1.
Thanks.
- Asiri
Hi,
After discussing with Thomas we've reached the conclusion that we
should change the way the HTML macro handle its content when wiki=true.
For ex take the following input:
{{velocity}}
...
{{html wiki="true"}}
<form>
$xwiki.includeForm("XWiki.MyClassSheet")
<br />
<p>
<input type="submit" name="submit" value="Create this new
Workpackage" />
</p>
</form>
{{/html}}
...
{{/velocity}}
And assume that MyClassSheet has some $doc.display() velocity code
which thus generate {{html}} macros.
Current Result
============
Right now here's what happens:
1) velocity macro is executed and $xwiki.includeForm executes
2) MyClassSheet generate {{html}} macro content thus yielding:
{{html wiki="true"}}
<form>
{{html}}...<someTag>...</someTag>{{/html}}
</form>
{{/html}}
3) After velocity has finished executing the velocity macro calls the
wiki parser on the result and thus the top level HTML macro executes
4) since wiki=true the content is given to a SAX parser and each XML
tag content is given to the wiki parser. Thus "{{html}}...", "..." and
"{{/html}}" will be parser by the wiki parser separately (because
<someTag> is valid XML), thus generating non expected content as a
result.
Proposed change
==============
Modify the HTML behavior so that the wiki parser executes first
(instead of the SAX parser) and render the result using a special
renderer that prints the special symbols and text as is.
When run on our example this would give (same steps 1) and 2)):
3) wiki parser executes and generate XDOM. Render it using the special
renderer
Note that this means that if in HTML your write content that has a
meaning in some wiki syntax you'll need to escape it. For example if
you have:
{{html wiki=true}}
<!--hello-->
{{/html}}
you'll get some strikethrough. So you'll need to write instead:
{{html wiki=true}}
<!~-~-hello~-~->
{{/html}}
WDYT?
Here's my +1
Thanks
-Vincent
Hi Devs,
I was working on openoffice server auto-start feature and faced a few
problems with it.
To start the openoffice server when XE is started, I need to send a
notification to openoffice server manager when XE is started. The first
attempt was to use our ObservationManager component to send startup /
shutdown events and let OpenOfficeServerManager listen to them. But this
approach requires that OpenOfficeServerManager component is loaded on XE
startup so that it can recieve the startup notification.
As a solution I tried to use <load-on-startup> components list in plexus.xml
file but since OpenOfficeServerManager has a dependancy on
ConfigurationSourceCollection component, it fails to load on startup. This
is because ConfigurationSourceCollection requires a valid ApplicationContext
to be present for it's operation but at the time plexus is loading
<load-on-startup> components, no ApplicationContext is present. The core
issue is, plexus is initialized before we initialize ApplicationContext; and
we can't change this order either.
Since the above approach is not going to work, I propose to introduce an
ApplicationContextInitializer component pretty much alike RequestInitializer
and ExecutionContextInitializer. The idea is to allow any component to do
further initializations on ApplicationContext if they need to do so. When XE
is started up and an ApplicationContext is created,
ApplicationContextInitializerManager will lookup for all the components that
implement ApplicationContextInitializer and let them a chance to execute
their own initializations.
But this doesn't solve the problem of shutdown notifications. For shutdown
notifications we can either use the plain old ObservationManager component
or we can do the following; rather than having ApplicationContextInitializer
and ApplicationContextInitializerManager, we will have
ApplicationContextListener and ApplicationContextListenerManager.
ApplicationContextListener will have two methods like contextCreated() and
contextDestroyed() that will allow any component to perform startup /
shutdown tasks. But still, I don't see where we can invoke
contextDestroyed() method from, I looked at both servlet container API and
portlet container API and couldn't find a consistent way of invoking the
contextDestroyed() method.
Please let me know what you think about this idea.
Thanks.
- Asiri
Hi devs,
We've been tackling this proposal for some time, but we never took a
final decision on it. So, I propose that we do this switch as soon as
possible.
Changes:
- default encoding UTF-8 in the start_xwiki* scripts, xwiki.cfg and web.xml
- remove the LANG= environment variable from the start script, since
it's not needed
- add the encoding configuration for the mysql jdbc connection URL
(http://dev.mysql.com/doc/refman/5.0/en/connector-j-reference-charsets.html)
Implications:
- hsqldb instances will continue to work fine
- for mysql and other DB instances, either the DB will need to be
changed to work with the new encoding, or the wiki will have to be
changed back to 8859-1. If we append characterEncoding=UTF-8 to the
connection URL, then the storage will throw exceptions when trying to
store an incompatible character, thus admins will quickly notice the
problem and solve the issue, before users report loosing characters
after a while (since without this setting the characters are silently
transformed to '?' and this won't be noticed until the cache expires).
We need to highlight this change in the release notes and upgrade
instructions.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
I'm proposing to have another point release for XE 1.8.x called 1.8.3.
XE 1.8.2 is planned for the 20th of April and I propose to plan 1.8.3
for two weeks after, i.e. 4th of May.
As usual the goal is to include important bug fixes. The reason I
think we need a 1.8.3 is because we're starting to get feedback from
our new wysiwyg/new rendering and we need to bring bug fixes as fast
as possible to our users without forcing them to wait for 1.9 final.
Here's my +1
Thanks
-Vincent
Hello,
Because of personal reasons i decided not to continue contributing to XWiki
development.
Thanks a lot for all your guidance and a wish you good luck in everything,
it was really nice being part of this community !
With great respect, Ancuta