hi,
my request is about customizing xwiki from its war file
i.e make the forum plugin that i have(BulletinBoardApplication2.xar) an original component of the application, by the way i don't know if there's a better forum plugin :) and that's including also changing the skins and the backgroud of the "first generated application",threre's another question how add a link to forum component in the quick links panel (* [Forum>Main.BulletinBoard]?? )
help me with this one please
thank you
--
View this message in context: http://n2.nabble.com/customize-xwiki-tp2543791p2543791.html
Sent from the XWiki- Dev mailing list archive at Nabble.com.
Hi xWiki Devs,
I'm a computer engineering undergrad from university of moratuwa and i'm really interested computer security, network security, cryptography. Hence i'm curious about this xWiki project idea for Gsoc 09 called anit vandalism filter which seems to be very interesting. So i'm very keen to know more about this project, specially scope, dependencies and requirements before submitting my project proposal. I appreciate some more details and feed back about this.
Thanks & Regards,
Harashna Martin
--
View this message in context: http://n2.nabble.com/Anti-Vandalism-Filter-For-GSoc-09-tp2543640p2543640.ht…
Sent from the XWiki- Dev mailing list archive at Nabble.com.
Hi devs,
Currently in the html macro the wiki parser is applied.
That means that if you expected the html you put inside the macro you
could have unpleasant surprises.
I think putting just html in the html (eventually some velocity) is
the most common use case and it's easier for a user to understand that
the wiki content inside the html macro is not applied because it's not
enabled that "this does not looks like the html I put". Another way to
say it is that we will get a lot more mail on the list with wiki=true
than wiki=false ;)
I propose to change wiki=true by wiki=false by default.
Here is my +1
--
Thomas Mortagne
Hi devs,
I'm continuing on this topic since I really believe we need
annotations now. However I think it's best to have our own annotations
for injection.
One reason we need annotation (amongst other needs) is in order to be
able to create a xwiki uberjar for rendering modules for example. With
components.xml you cannot easily merge jars since you'd need to merge
components.xml so you'd need to write some xslt code for that.
Another reason is that we have to comment in the code things such as
"this field is injected automatically by the component manager". Of
course this comment is forgotten most of the time. It's much nicer to
have a @Inject annotation.
Last we need annotations if we want to be able to more easily support
different IOC frameworks since otherwise it means that for each fwk we
need to do again all components mappings in a static way.
Of course one basic need is evidently to reduce the number of config
lines we have to write and the errors associated with them.
I'm going to look into plexus annotations for a starter (+ guice) to
see how they do it and then I'll make a proposal for annotations.
Let me know what you think.
Thanks
-Vincent
Hi,
To start with I propose to model against the plexus annotations but
more simple:
* Component
* Requirement
* Configuration
/**
* Marks a class as a XWiki component.
*/
@Documented
@Retention(RUNTIME)
@Target(TYPE)
@Inherited
public @interface Component
{
Class<?> role();
String hint() default "";
String instantiationStrategy() default "";
}
/**
* Configures a requirement.
*/
@Documented
@Retention(RUNTIME)
@Target({ FIELD, METHOD })
@Inherited
public @interface Requirement
{
Class<?> role() default Object.class;
String hint() default "";
//
// HACK: This is here to support component requirement lists,
which can take a list of hints
//
String[] hints() default {};
}
Note: not sure yet why plexus says it's a hack.
/**
* Marks a field as a configuration element with a default value.
*/
@Documented
@Retention(RUNTIME)
@Target(FIELD)
@Inherited
public @interface Configuration
{
String name() default "";
String value();
}
So for example in the code you'd have:
@Component(role=Parser.class)
public class WikiModelXWikiParser implements Parser...
{
@Requirement
private LinkParser linkParser;
....
wdyt?
I'm still researching.
Thanks
-Vincent
Hi,
I'm proposing that we release XE 1.8.1 on the 6th of April. It would
have been 3 weeks since the release of 1.8 and we'll have plenty of
important fixes and improvements for our users. Note that 1.8.1 is
mainly for rendering/wysiwyg improvements.
The roadmap is currently defined in jira:
- For wysiwyg
http://tinyurl.com/d75olg
- For rendering
http://tinyurl.com/cwpchk
Note that more issues will be put for rendering and other domain. The
idea is to time box this for the 6th of April.
Here's my +1
Thanks
-Vincent