Hi,
I don't think we need different Macro Sources in the rendering module.
All we need is a single source that takes its macros from the
classloader.
What we do need are different modules that create Macro components so
that they are made available to the single Macro Source.
For example the annotations are defining macros and their not a
source. They don't need to be. All they have to do is call
ComponentManager.registerComponent() to register new macros.
The same should be done for macros defined as wiki pages or macros
defined in a remote repository. All we need are handlers that can
extract information and generate calls to
ComponentManager.registerComponent().
Now since we need to be performant we want to cache Macros at init
time in the Macro manager but we also need to support macros added
dynamically later on. For this I think we need to introduce Component
Manager events (this already exists in Plexus BTW) that would allow
listeners to get events when a component is created or disposed of. In
this manner the Macro Manager would subscribe to CM events for the
Macro.class role and be able to add/remove Macros on the fly.
WDYT?
Thanks
-Vincent
Hi Niels,
thanks for your feedback.
On Fri, May 15, 2009 at 12:03 AM, Niels Mayer <nielsmayer(a)gmail.com> wrote:
> On Thu, May 14, 2009 at 2:01 AM, Marius Dumitru Florea <
> mariusdumitru.florea(a)xwiki.com> wrote:
>
> >
> > For the first outcome I think we all agree that the user has to press
> > Shift+Enter. For the second and third outcomes I see two options:
> >
> > A) Enter for 2 and CTRL/META+Enter for 3
> > B) Enter for 3 and CTRL/META+Enter for 2
> > (if you see any other options please step up)
> >
>
> Sounds like wikimacs (wiki+emacs) :-)
>
> What about using a multiple-repeated enters. Kind of like a keyboard
> equivalent of a double, triple click, with some visual way of suggesting
> what level "upwards" in the DOM the return will create the next element
> (e.g
> a "box insertion caret" like for drag-drop operations):
>
> * a single enter in a list adds a paragraph or <br> within the current
> element. It does not create a new list or table entry.
>
> * double-enter, creates a new <li> <tr> etc (depending on if you're in a
> table, list etc) within the current table/list.
>
> * triple-enter, creates a new <li> <tr> <p> or <br> as the next element
> outside of the current list/table etc. (if in a nested table/list, it'll
> correctly add the next element)
We tried doing something similar for paragraphs (hit enter once to create
next line, twice for new paragraph) and the feedback we got from users was
pretty negative. It looks like the user's expectation about the enter key is
that it will create a new item (new paragraph, new list item, new whatever).
Thus the concept of double-enter similar to double-clicking doesn't seem to
work in practice so far. Thus I think we shouldn't reintroduce it.
-- Niels
> http://nielsmayer.com
>
> PS: I got to deal with all these fun issues back in ~1995 when i designed
> WWWeasel (reviewed at an early WWW conf
> here<http://nielsmayer.com/L27933-1529TMP.pdf>
> )
> http://nielsmayer.com/wwweasel/node26.html<
> http://nielsmayer.com/wwweasel/node26.html#SECTION00051000000000000000>
> http://nielsmayer.com/wwweasel/node27.html
> It is very helpful for the user to be able to see what's going on
> "structurally" at the same time as you're editing in WYSIWYG.... If you can
> graphically depict where in the DOM structure the "return" is pointing, at
> what level of scope, then it's a lot less confusing to the user.
The WYSIWYM concept is pretty interesting and powerful. I played around with
tools such as WYMeditor
http://files.wymeditor.org/wymeditor/trunk/src/examples/01-basic.html
and I definitely do like the concept. However, this is not the direction we
have taken so far with our new WYSIWYG editor. Changing it to make it a
WYSIWYM editor on top of what it currently does would require considerable
effort. Our focus right now is on eliminating quirks and bugs in all major
browsers to make the editor ready for production use. Therefore I think
we'll have to wait some time before even considering building a WYSIWYM
editor for XWiki.
However, please note that since you can store XWiki document contents as
XML, you could definitely try to plug WYMeditor on top of XWiki and make it
the default edition option. You'd lack the wiki-specific feature, but for
content insertion you'd benefit from the WYSIWYM interface :-)
Guillaume
> _______________________________________________
> users mailing list
> users(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/users
>
--
Guillaume Lerouge
Product Manager - XWiki
Skype ID : wikibc
http://guillaumelerouge.com/
I have a servlet I am porting from another environment that only needs a few services from XWiki (mostly user authentication and group membership). Is there a recommended way of getting a handle to an XWiki instance from a servlet that derives from HttpServlet? I was looking for some sort of static method I could invoke to retrieve this but haven't come across one yet.
Suggestions would be appreciated.
Thanks,
Glenn
Hi there,
Right now the new WYSIWYG editor allows us to create simple lists like
the following:
----------8<----------
* plants
* animals
** invertebrates
** vertebrates
---------->8----------
By pressing just Enter when the caret is inside a list item we create a
new list item. This is the basic mechanism. It's simple and it should
remain so.
If I want to make the previous list a bit more complex:
----------8<----------
* (((= Plants =
Plants are living organisms belonging to the kingdom Plantae.)))
* (((= Animals =
Animals are a major group of mostly multicellular, eukaryotic organisms
of the kingdom Animalia or Metazoa.
They are divided into:)))
** (((== Invertebrates ==
An invertebrate is an animal lacking a vertebral column.)))
** (((== Vertebrates ==
Vertebrates are members of the subphylum Vertebrata, chordates with
backbones or spinal columns.)))
---------->8----------
I have to be able to insert new lines inside a list item using the Enter
key but without creating a new list item. Let's consider the following
state:
----------8<----------
* (((= Plants =)))
---------->8----------
We have a level 1 heading inside a list item. The caret is inside the
heading, at the end. Pressing Enter can have the following three outcomes:
1. Continue editing in the heading, but on a new line:
----------8<----------
* (((= Title 1
x =)))
---------->8----------
2. Continue editing in the same list item but after the heading, in a
paragraph:
----------8<----------
* (((= Title 1 =
x)))
---------->8----------
3. Create a new list item:
----------8<----------
* (((= Title 1 =)))
* x
---------->8----------
For the first outcome I think we all agree that the user has to press
Shift+Enter. For the second and third outcomes I see two options:
A) Enter for 2 and CTRL/META+Enter for 3
B) Enter for 3 and CTRL/META+Enter for 2
(if you see any other options please step up)
I'm +1 for A) for the following reason: if the user has inserted a
heading in a list item then he will surely want to add more content
after that heading, thus pressing just Enter is the natural way of doing
this. From a technical POV the caret is first inside a heading and then
inside a list item so the heading should have the priority of handling
the Enter key.
NOTE: Choosing A) or B) doesn't affect the way simple lists are created,
which is using just Enter.
Please cast your votes and sorry for the long mail,
Marius
In 1.8, if too much data is entered in a doc's ?editor=object
fieldXWiki.JavaScriptExtension[] (say
a big chunk of JSON on the order of 97783 bytes) you can no longer save
without getting an underlying error. This appears related to the following:
com.xpn.xwiki.objects.LargeStringProperty -->
com.mysql.jdbc.MysqlDataTruncation:
Data truncation: Data too long for column 'XWL_VALUE' at row 1
How can this be changed to allow for a larger limit on entries? Fortunately,
http://nielsmayer.com/xwiki/bin/view/Exhibit/Presidents3 ( src
<http://nielsmayer.com/xwiki/bin/download/Exhibit/Presidents3/Exhibit.Presid…>)
has entries small enough, but as you grow the amount of Javascript data you
hold in a XWiki.JavaScriptExtension you eventually get a failure like this:
A problem occured while trying to process your request. Please contact the
> webmaster if this happens again.
>
> Detailed information:
>
> Error number 3201 in 3: Exception while saving document Exhibit.pods
> Wrapped Exception: could not update: [com.xpn.xwiki.objects.LargeStringProperty#component[id,name]{id=-2025184002, name=code}]
> com.xpn.xwiki.XWikiException: Error number 3201 in 3: Exception while saving document Exhibit.pods
> Wrapped Exception: could not update: [com.xpn.xwiki.objects.LargeStringProperty#component[id,name]{id=-2025184002, name=code}]
> at com.xpn.xwiki.store.XWikiHibernateStore.saveXWikiDoc(XWikiHibernateStore.java:595)
> at com.xpn.xwiki.store.XWikiCacheStore.saveXWikiDoc(XWikiCacheStore.java:135)
> at com.xpn.xwiki.store.XWikiCacheStore.saveXWikiDoc(XWikiCacheStore.java:128)
> at com.xpn.xwiki.XWiki.saveDocument(XWiki.java:1282)
> at com.xpn.xwiki.web.SaveAction.save(SaveAction.java:176)
> at com.xpn.xwiki.web.SaveAndContinueAction.action(SaveAndContinueAction.java:64)
> at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:215)
> at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:115)
> at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431)
> at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236)
> at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)
> at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432)
>
> ...
>
> Wrapped Exception:
>
> com.mysql.jdbc.MysqlDataTruncation: Data truncation: Data too long for column 'XWL_VALUE' at row 1
> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:2983)
> at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1631)
> at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:1723)
> at com.mysql.jdbc.Connection.execSQL(Connection.java:3256)
> at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:1313)
> at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:1585)
> at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:1500)
> at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:1485)
> at org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:101)
> at org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:101)
> at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2412)
> at org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:2312)
> at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2612)
> at org.hibernate.action.EntityUpdateAction.execute(EntityUpdateAction.java:96)
> at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:279)
> at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:263)
> at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:168)
> at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:298)
> at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27)
> at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
> at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:338)
> at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:106)
> at com.xpn.xwiki.store.XWikiHibernateBaseStore.endTransaction(XWikiHibernateBaseStore.java:866)
> at com.xpn.xwiki.store.XWikiHibernateBaseStore.endTransaction(XWikiHibernateBaseStore.java:837)
> at com.xpn.xwiki.store.XWikiHibernateStore.saveXWikiDoc(XWikiHibernateStore.java:585)
> at com.xpn.xwiki.store.XWikiCacheStore.saveXWikiDoc(XWikiCacheStore.java:135)
> at com.xpn.xwiki.store.XWikiCacheStore.saveXWikiDoc(XWikiCacheStore.java:128)
> at com.xpn.xwiki.XWiki.saveDocument(XWiki.java:1282)
> at com.xpn.xwiki.web.SaveAction.save(SaveAction.java:176)
> at com.xpn.xwiki.web.SaveAndContinueAction.action(SaveAndContinueAction.java:64)
>
>
Thanks.
Niels
http://nielsmayer.com
I'm having a difficult time adding a java macro and getting it to get invoked.
I first found this page and created my class and created a META-INF/plexus/components.xml per the 'tutorial' here: http://dev.xwiki.org/xwiki/bin/view/Drafts/Tutorial+to+Write+a+Macro+in+the…
I then found this tutorial for components (http://platform.xwiki.org/xwiki/bin/view/DevGuide/WritingComponents) and created a META-INF/components.txt file and added an @Component("mymacro") annotation to the macro implementation.
However, I am unable to get my macro code to get called when pages are rendered.
Is there something else I'm missing? I've verified all the relevant files are in my jar.
--
Glenn
Hi,
I wanted to see if we could move our LogEnabled lifecycle phase to a
Logging component. I think it's not going to work since this means
injecting a LoggingFactory/LoggingManager component and you need to
call getLogger(this.getClass()) to get access to the Logger which is
awkward.
What I propose:
1) Use SLF4J (drop the slf4j-log4j jar in our WEB-INF/lib so that
SLF4J uses log4j by default)
2) Drop the JCL/JUL/LOG4j SLF4J legacy jars in our WEB-INF/lib too
and exclude the JCL/JUL/LOG4J jars from our poms so that all third
party logs go to our logging system
3) Non component code should use a SLF4J's LoggerFactory directly
4a) Keep LogEnabled and AbstractLogEnabled for our components
or
4b) Automatically inject a Logger and a ComponentManager when there
are fields with these types in a component class.
I like 4b) for its simplicity but I'm worried by the "magical" aspect
of it.
WDYT?
Thanks
-Vincent