Re: searching for a Rich text editor
The last 3 days I have tried all of the mentioned RTE but I had some trouble with each, I would like to share my experiences. I am using apache-wicket (version 1.5.10 currently in maven project) for 2 years and I like it so much but sometimes when I want to add a new component I fail with it. Visural-wicket: easy to work with it, nice looking, but in IE 8 when the edit area extends, it overlaps the bottom area and looks quite bad, I have not found hungarian localization TinyMCE: easy to work with it, nice looking, hungarian translations are there, but the popup windows resizes too small in Chrome and IE 8 only Firefox keeps the popup window size properly, the others alwasy have to resize with mouse Kendo UI: extremely nice on demo page, but I can not work with it at all, it includes javascript resources even if I included the resources on top of page, I do not know how can I disable the unwanted extra resource loading at page head I would really appreciate if anybody could suggest something in any RTE modules. Thx. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/searching-for-a-Rich-text-editor-tp4662506p4663124.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: 1.4.7 app form does not submit on server when panel is not visible.
That's too much code to dissect in an email.
Create a quickstart please.
Sven
On 12/18/2013 07:29 PM, Entropy wrote:
This is in one of our Wicket 1.4.7 apps that we have not converted yet. The
problem does not happen in localhost test environments, but does happen on
the server. Moreover, the problem only happens when a data condition causes
a particular panel to be visible.
When this panel is visible (and I pick that because it is the only major
difference between it working and failing), the page does not submit. I hit
the submit button, and rather than advancing to the next page, the current
page redisplays with no validation errors displayed.
Loig statements at the top of every event do not fire. Log statements at
the top of the validate methods of the three validators applied to the form
do not fire.
The panel itself seems fairly nondescript:
private void buildEDocPanel() {
WebMarkupContainer wmc = new WebMarkupContainer(eDocsWrapper);
DocTypeSelect docTypes = new DocTypeSelect(eDocTypes,
model.geteDocTypes()) {
private static final long serialVersionUID = 1L;
@Override
public ListFilterValue loadDocumentTypes() {
return
lookupService.fetchFilterValuesByFilterName(Document Type);
//Document Type
}
};
form.add(wmc);
wmc.add(docTypes);
wmc.setVisible(model.getApplicationCode().equals(UMCConstants.APPL_EDOCS));
}
DocTypeSelect is a custom panel that implements a wizard-y control where one
side has a master list and you pick which ones to add to the right side's
list with add/remove buttons in the middle. The code for this panel is
below. Based on the log, the onAddSelected method and onSelectionChange
method fire, but both of those are BEFORE the page submit.
The HTML for the submit button is:
input type=submit class=submit btnsubmit wicket:id=nextBtn
onclick=document.ignoreDirty=true;return true; value=Step 3: Review
gt;
The onclick is for a are you sure you want to leave since you have made
changes kind of warning in javascript. It doesn't interfere in localhost
or if the panel is not visible, and when it prevent departure, the page
wouldn't reload, so i am mostly sure that isn't the problem, but I present
that it is an input type submit since that has sometimes made a difference
during my experience with wicket.
public abstract class DocTypeSelect extends Panel {
private static final long serialVersionUID = 1L;
private static Logger log = Logger.getLogger(DocTypeSelect.class);
private ListFilterValue selected;
private ListMultipleChoiceFilterValue ddAvailable;
private ListMultipleChoiceFilterValue ddSelected;
public DocTypeSelect(String id, ListFilterValue selectedDocTypes) {
super(id);
selected = selectedDocTypes;
init();
}
private void init() {
buildLeftSide();
buildCenter();
buildRightSide();
}
public abstract ListFilterValue loadDocumentTypes();
public void onSelectionChange(AjaxRequestTarget target,
ListFilterValue
selected) {
log.debug(onSelectionChange());
}
@SuppressWarnings({ unchecked, rawtypes })
private void buildLeftSide() {
ListFilterValue docTypes = loadDocumentTypes();
ddAvailable = new
ListMultipleChoiceFilterValue(docTypesAvailable,
new Model(new ArrayListFilterValue()),
docTypes,
new IChoiceRendererFilterValue() {
private static final long
serialVersionUID = 1L;
@Override
public Object
getDisplayValue(FilterValue arg0) {
return
arg0.getFilterValueDecode();
}
@Override
public String getIdValue(FilterValue
arg0, int arg1) {
return arg0.getFilterValue();
}
});
add(ddAvailable);
}
private void buildCenter() {
add(new AjaxButton(addSelected) {
private static final long serialVersionUID = 1L;
@SuppressWarnings({ rawtypes })
@Override
protected void onSubmit(AjaxRequestTarget target, Form
form) {
onAddSelected(target);
}
Re: searching for a Rich text editor
Hi, For the Kendo UI one, the way to include resource is explained here: https://github.com/sebfz1/wicket-jquery-ui/wiki/%5Bhowto%5D-change-resources-references Best regards, Sebastien. On Thu, Dec 19, 2013 at 9:21 AM, mkrivan mik...@krivan.hu wrote: The last 3 days I have tried all of the mentioned RTE but I had some trouble with each, I would like to share my experiences. I am using apache-wicket (version 1.5.10 currently in maven project) for 2 years and I like it so much but sometimes when I want to add a new component I fail with it. Visural-wicket: easy to work with it, nice looking, but in IE 8 when the edit area extends, it overlaps the bottom area and looks quite bad, I have not found hungarian localization TinyMCE: easy to work with it, nice looking, hungarian translations are there, but the popup windows resizes too small in Chrome and IE 8 only Firefox keeps the popup window size properly, the others alwasy have to resize with mouse Kendo UI: extremely nice on demo page, but I can not work with it at all, it includes javascript resources even if I included the resources on top of page, I do not know how can I disable the unwanted extra resource loading at page head I would really appreciate if anybody could suggest something in any RTE modules. Thx. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/searching-for-a-Rich-text-editor-tp4662506p4663124.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: wicket-el - is this a safe way to hook into wicket?
Hi, I'm glad you are making progress with your adventure! On Thu, Dec 19, 2013 at 7:40 AM, Steve Coughlan shadders@gmail.comwrote: A few weeks back I made a post about the first version of universal expression language for wicket. Since then it's come quite a way. The initial version hooked into by implementing IMarkupResourceStreamProvider for markup owning MarkupContainers (Panel, Page etc...) and by regenerating markup fragments for markup receiving MarkupContainers (ListView). Unfortunately due to the fact that the EL expressions need to be evaluated on every request this meant a huge performance hit (about 75% less than standard wicket) due to forcing wicket to constantly parse markup on every request cycle. The current evolution of wicket-el hooks in very differently. My first preference was to create a dynamic version of Markup and MarkupFragment that replaces MarkupElements that contain EL expressions with a dynamic version. Unfortuantely this was impossible because I need to subclass Markup (wicket uses a few case of 'instanceof Markup') and Markup has many final methods. And simply wrapping all the MarkupElements isn't possible because RawMarkup is a final class and is also reference inside wicket with 'instanceof'. So far no one needed to add custom MarkupElements and that's why it is not very easy. You can fork Wicket and create a branch where you can make modifications to make it easier and later we can review the needed changes and probably apply them back in Wicket. So the only way I could think of to do it (which I've done and it works) is to create a subclass of Markup (ModifiableMarkup) that takes the original wicket-parsed markup, and adds all it's elements. Then during the onRender phase EL enabled components call ModifiableMarkup.resolve(ExpressionResolver, ELParseMatchList) which internally replaces RawMarkup elements belonging to that compenent with an EL resolved version. This is done just before calling super.onRender(). Sounds ugly but it works and performance is now equal to standard wicket (in some cases can even be a little faster due to not needing PropertyModels). Because the Markup instances are now mutable I can't use wicket's markup cache as it's one per class and ModifiableMarkup.resolve method could easily be called by many threads at once. So I've had to implement caching per thread/class combination. i.e. ELPanel will have a cached instance of Markup for every thread. My question is twofold: 1/ As I have no choice but to leave ModifiableMarkup mutable, what is the purpose of making Markup immutable? From what I can see from browsing wicket source all it achieves is a bit of safety and releasing some resources from the backing XmlTags in the MarkupElements. Is there any other purpose to it? i.e. can you forsee any problems with using a mutable instance of Markup for rendering? Why ModifiableMarkup has to be mutable ? Do you expect that the markup will change at runtime in some conditions ? I think what you need is a new impl of MarkupElement for the expressions. So org.apache.wicket.markup.Markup#markupElements will have more elements. Then when rendering starts each element will render itself as appropriate. But the list itself won't change once created. If the developer changes the markup then the whole Markup instance is replaced with a new one. As now. 2/ Is the per thread/class caching strategy really safe? The only way I could think it could be broken is if it was possible for the server to suspend a thread mid-render cycle and give another request use of that thread. If that happened the new request would overwrite the markup expressions and the when the old resumed and expressions already resolved would have values from the the request that interrupted it. As far as I'm aware with the work I've done with Jetty and NIO connectors before this will only happen if you ask Jetty to do it while processing the request. Is this a possibility with wicket or can I rely on a complete render cycle to happen uninterrupted before the thread is reused for another request? It is safe to assume that exactly one thread will process the request. This is how Wicket's thread locals work today. Using Servlet 3.0 AsyncContext in a page will break many other things.
Re: wicket-el - is this a safe way to hook into wicket?
Why ModifiableMarkup has to be mutable ?
Do you expect that the markup will change at runtime in some conditions ?
I think what you need is a new impl of MarkupElement for the expressions.
So org.apache.wicket.markup.Markup#markupElements will have more elements.
Then when rendering starts each element will render itself as appropriate.
But the list itself won't change once created.
Yes markup will change at runtime. It is primarily because of
RawMarkup. It is a final class and there are several examples of: if
(element instanceof RawMarkup) do something; in wicket so when
resolving the EL expressions in the markup the only 'safe' way to do it
and stay completely transparent to wicket is to replace the original
RawMarkup with a new one... e.g.
in the EL component:
public void onRender() {
modifiableMarkup.resolve(some params);
super.onRender();
}
What it looks like inside MarkupModifier.resolve() is something like this:
original RawMarkup.toString: span${myProperty}/span
resolved = new RawMarkup(spanmy property value/span);
modifiableMarkup.replace(rawMarkupIndex, resolved);
(actually it's not really relevant to this discussion but the original
RawMarkup contains a marker token instead of the original expression to
ensure it's XML legal before it's passed to the markup parser... in this
case it would be '${#[expressionIndex]}' )
here's a link to ModifiableMarkup
https://bitbucket.org/shadders/wicket-el/src/917bb51f19ddd6e631d8ce537c90915eb21fb01f/src/main/java/org/apache/wicket/markup/ModifiableMarkup.java?at=default
So I can't call makeImmutable() on ModifiableMarkup or it will throw an
exception whenever replace(index, markupElement) is called. However the
length of the element list will never change and each element in the
list will always be the same type.
If the developer changes the markup then the whole Markup instance is
replaced with a new one. As now.
That's the entire purpose of this approach... To avoid that. The
overhead from continually recreating Markups was enormous.
So far no one needed to add custom MarkupElements and that's why it is not
very easy.
You can fork Wicket and create a branch where you can make modifications to
make it easier and
later we can review the needed changes and probably apply them back in
Wicket.
I may give that a go. This has been an interesting exercise that's
forced to spend a lot of time under the hood in wicket getting to know
the markup sourcing and rendering aspects of it. I must confess I was a
little concerned the wicket team might not like this project much given
that it's fairly hefty divergence from the wicket way of doing
things... Wonderful to hear you are open to considering some minor
changes to accomodate it.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: wicket-el - is this a safe way to hook into wicket?
On Thu, Dec 19, 2013 at 11:49 AM, Steve shadders@gmail.com wrote:
Why ModifiableMarkup has to be mutable ?
Do you expect that the markup will change at runtime in some conditions ?
I think what you need is a new impl of MarkupElement for the expressions.
So org.apache.wicket.markup.Markup#markupElements will have more
elements.
Then when rendering starts each element will render itself as
appropriate.
But the list itself won't change once created.
Yes markup will change at runtime. It is primarily because of
RawMarkup. It is a final class and there are several examples of: if
(element instanceof RawMarkup) do something; in wicket so when
resolving the EL expressions in the markup the only 'safe' way to do it
and stay completely transparent to wicket is to replace the original
RawMarkup with a new one... e.g.
in the EL component:
public void onRender() {
modifiableMarkup.resolve(some params);
super.onRender();
}
What it looks like inside MarkupModifier.resolve() is something like this:
original RawMarkup.toString: span${myProperty}/span
resolved = new RawMarkup(spanmy property value/span);
modifiableMarkup.replace(rawMarkupIndex, resolved);
My idea is to use something like ElMarkupElement instead of RawMarkup when
there are EL expressions inside.
Then each ElMarkupElement will resolve its value when requested
(org.apache.wicket.markup.MarkupElement#toCharSequence, I think).
You can put the params in the request cycle metadata, or custom thread
local, ...
This way the Markup instance is always the same, its markup elements are
always the same, but the output they produce is different depending on the
context information.
To accomplish this you will need to tweak the MarkupParser though.
The good thing is that Wicket parses the markup just once and then puts it
in the cache.
(actually it's not really relevant to this discussion but the original
RawMarkup contains a marker token instead of the original expression to
ensure it's XML legal before it's passed to the markup parser... in this
case it would be '${#[expressionIndex]}' )
here's a link to ModifiableMarkup
https://bitbucket.org/shadders/wicket-el/src/917bb51f19ddd6e631d8ce537c90915eb21fb01f/src/main/java/org/apache/wicket/markup/ModifiableMarkup.java?at=default
So I can't call makeImmutable() on ModifiableMarkup or it will throw an
exception whenever replace(index, markupElement) is called. However the
length of the element list will never change and each element in the
list will always be the same type.
If the developer changes the markup then the whole Markup instance is
replaced with a new one. As now.
That's the entire purpose of this approach... To avoid that. The
overhead from continually recreating Markups was enormous.
So far no one needed to add custom MarkupElements and that's why it is not
very easy.
You can fork Wicket and create a branch where you can make modifications
to
make it easier and
later we can review the needed changes and probably apply them back in
Wicket.
I may give that a go. This has been an interesting exercise that's
forced to spend a lot of time under the hood in wicket getting to know
the markup sourcing and rendering aspects of it. I must confess I was a
I am not the best person to guide you in this part of Wicket.
Because markup handling was relatively bug-free in the last years I haven't
spent much time in this area.
Also there were no many brave souls to do something like you :)
little concerned the wicket team might not like this project much given
that it's fairly hefty divergence from the wicket way of doing
things... Wonderful to hear you are open to considering some minor
changes to accomodate it.
I personally do not like EL per se.
But I see no problem to make it easier for external projects to hook in
every part of Wicket to accomplish whatever is needed, as far as the core
functionality of Wicket is not harmed by this.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: 1.4.7 app form does not submit on server when panel is not visible.
Yeah, I get that. The problem with that is that I can't reproduce the issue locally with the FULL APPLICATION, so I am reasonably certain that I won't be able to reproduce it with a quickstart. It only happens on the server AND when this panel is visible. I attached the panel as a file if that would help. I did this through nabble's upload file interface, so I am not sure how that arrives to you...I would hope as an email attachment? My next step was that I set all org.apache.wicket to DEBUG in log4j. This produces quite alot of noise, but I am mostly confident that I got the statements for that request figured out. There's a bunch of these before and after: 2013-12-19 07:27:57,035 - org.apache.wicket.util.thread.Task - DEBUG - Run the job: org.apache.wicket.util.watch.ModificationWatcher$1@65586558 2013-12-19 07:27:57,036 - org.apache.wicket.util.thread.Task - DEBUG - Finished with job: org.apache.wicket.util.watch.ModificationWatcher$1@65586558 But i don't think those are relevant. The block then begins: 2013-12-19 07:27:57,054 - org.apache.wicket.Session - DEBUG - Getting page [path = 6:form, versionNumber = 0] 2013-12-19 07:27:57,055 - org.apache.wicket.Component - DEBUG - Begin render [Page class = gov.usdoj.afms.umc.modules.UM10.Step2_Criteria, id = 6, version = 0] 2013-12-19 07:27:57,056 - org.apache.wicket.MarkupContainer - DEBUG - Rendering raw markup 2013-12-19 07:27:57,056 - org.apache.wicket.MarkupContainer - DEBUG - Add _header_16 to [Page class = gov.usdoj.afms.umc.modules.UM10.Step2_Criteria, id = 6, version = 0] 2013-12-19 07:27:57,056 - org.apache.wicket.Component - DEBUG - Begin render [MarkupContainer [Component id = _header_16]] 2013-12-19 07:27:57,057 - org.apache.wicket.MarkupContainer - DEBUG - Rendering raw markup 2013-12-19 07:27:57,057 - org.apache.wicket.MarkupContainer - DEBUG - Add _relative_path_prefix_17 to [MarkupContainer [Component id = _header_16]] After the first line, this Begin Render pattern repeats itself many times with varying components. But what I found interesting is that the only line between the modifcation block and the render block was that Getting page line. This implies to me that wicket didn't forward the event to any application code, it just repainted the page as if it were a refresh. I also notice that the URL never changes. It is: http://dev-catsapp-01:9085/ManagementCenter/?wicket:interface=:6 both before and after the request. I am used to seeing wicket increment that number, like a request counter, excepting when I am on a bookmarkable page. That is how it works in localhost as well. DocTypeSelect.java http://apache-wicket.1842946.n4.nabble.com/file/n4663130/DocTypeSelect.java -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/1-4-7-app-form-does-not-submit-on-server-when-panel-is-not-visible-tp4663114p4663130.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: 1.4.7 app form does not submit on server when panel is not visible.
New Info:
So I've been promoting over and over, having backed the panel out and slowly
building it back up. When I don't build the buttons in the middle, the page
submits normally. The html for the buttons is:
div id=tabbuttons
button type=button title=Add
wicket:id=addSelected/button
button type=button title=Add All
wicket:id=addAllgt;gt;/button
button type=button title=Remove
wicket:id=removeSelected/button
button type=button title=Remove All
wicket:id=removeAlllt;lt;/button
/div
the java is:
add(new AjaxButton(addSelected) {
private static final long serialVersionUID = 1L;
@SuppressWarnings({ rawtypes })
@Override
protected void onSubmit(AjaxRequestTarget target, Form
form) {
onAddSelected(target);
}
}.setDefaultFormProcessing(false));
add(new AjaxButton(addAll) {
private static final long serialVersionUID = 1L;
@SuppressWarnings({ rawtypes })
@Override
protected void onSubmit(AjaxRequestTarget target, Form
form) {
onAddAll(target);
}
}.setDefaultFormProcessing(false));
add(new AjaxButton(removeSelected) {
private static final long serialVersionUID = 1L;
@SuppressWarnings({ rawtypes })
@Override
protected void onSubmit(AjaxRequestTarget target, Form
form) {
onRemoveSelected(target);
}
}.setDefaultFormProcessing(false));
add(new AjaxButton(removeAll) {
private static final long serialVersionUID = 1L;
@SuppressWarnings(rawtypes)
@Override
protected void onSubmit(AjaxRequestTarget target, Form
form) {
onRemoveAll(target);
}
}.setDefaultFormProcessing(false));
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/1-4-7-app-form-does-not-submit-on-server-when-panel-is-not-visible-tp4663114p4663132.html
Sent from the Users forum mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: 1.4.7 app form does not submit on server when panel is not visible.
I can now add that if only the addSelected button is added, the problem
happens, likewise if only addAll is included. So it appears that any of the
four buttons creates the problem.
add(new AjaxButton(addSelected) {
private static final long serialVersionUID = 1L;
@SuppressWarnings({ rawtypes })
@Override
protected void onSubmit(AjaxRequestTarget target,
Form form) {
onAddSelected(target);
}
}.setDefaultFormProcessing(false));
button type=button title=Add wicket:id=addSelected/button
I should mention that nabble turned my greater than into a literal greater
than and same with less than. So if it looks like I have too many closing
tags in the button HTMLs, it's not true. I am using those character as
button captions.
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/1-4-7-app-form-does-not-submit-on-server-when-panel-is-not-visible-tp4663114p4663133.html
Sent from the Users forum mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: 1.4.7 app form does not submit on server when panel is not visible.
SOLVED I don't know why i didn't see this earlier, but the issue was using the button tag instead of input type=button. Somewhere along the line, someone started using button tags in our shop and we've noticed quirky behavior from them before (though nothing this quirky). Changed it to input control type button and it works. Though I do not understand why it behaved differently on the server than in localhost. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/1-4-7-app-form-does-not-submit-on-server-when-panel-is-not-visible-tp4663114p4663134.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: wicket-el - is this a safe way to hook into wicket?
On Wed, Dec 18, 2013 at 9:40 PM, Steve Coughlan shadders@gmail.com wrote: A few weeks back I made a post about the first version of universal expression language for wicket. Since then it's come quite a way. The initial version hooked into by implementing IMarkupResourceStreamProvider for markup owning MarkupContainers (Panel, Page etc...) and by regenerating markup fragments for markup receiving MarkupContainers (ListView). Unfortunately due to the fact that the EL expressions need to be evaluated on every request this meant a huge performance hit (about 75% less than standard wicket) due to forcing wicket to constantly parse markup on every request cycle. The current evolution of wicket-el hooks in very differently. My first preference was to create a dynamic version of Markup and MarkupFragment that replaces MarkupElements that contain EL expressions with a dynamic version. Unfortuantely this was impossible because I need to subclass Markup (wicket uses a few case of 'instanceof Markup') and Markup has many final methods. And simply wrapping all the MarkupElements isn't possible because RawMarkup is a final class and is also reference inside wicket with 'instanceof'. So the only way I could think of to do it (which I've done and it works) is to create a subclass of Markup (ModifiableMarkup) that takes the original wicket-parsed markup, and adds all it's elements. Then during the onRender phase EL enabled components call ModifiableMarkup.resolve(ExpressionResolver, ELParseMatchList) which internally replaces RawMarkup elements belonging to that compenent with an EL resolved version. This is done just before calling super.onRender(). Sounds ugly but it works and performance is now equal to standard wicket (in some cases can even be a little faster due to not needing PropertyModels). Because the Markup instances are now mutable I can't use wicket's markup cache as it's one per class and ModifiableMarkup.resolve method could easily be called by many threads at once. So I've had to implement caching per thread/class combination. i.e. ELPanel will have a cached instance of Markup for every thread. My question is twofold: 1/ As I have no choice but to leave ModifiableMarkup mutable, what is the purpose of making Markup immutable? From what I can see from browsing wicket source all it achieves is a bit of safety and releasing some resources from the backing XmlTags in the MarkupElements. Is there any other purpose to it? i.e. can you forsee any problems with using a mutable instance of Markup for rendering? because its immutable it is thread-safe. making it mutable would add a lot of complexity to make sure it is thread-safe. -igor 2/ Is the per thread/class caching strategy really safe? The only way I could think it could be broken is if it was possible for the server to suspend a thread mid-render cycle and give another request use of that thread. If that happened the new request would overwrite the markup expressions and the when the old resumed and expressions already resolved would have values from the the request that interrupted it. As far as I'm aware with the work I've done with Jetty and NIO connectors before this will only happen if you ask Jetty to do it while processing the request. Is this a possibility with wicket or can I rely on a complete render cycle to happen uninterrupted before the thread is reused for another request? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: searching for a Rich text editor
Thanks, yes, I have found it but unfortunately it is only for wicket 6 not for wicket 1.5. I already thinking on moving forward to 6 but I need to change quite a lot in the project so I need some more time to fullfill all of the wicket 6 changes. I think I have to choose tinymce now with the basic functionality. Hopefully it will be enough in our project. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/searching-for-a-Rich-text-editor-tp4662506p4663142.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
