On 11/25/05, Johan Compagner <[EMAIL PROTECTED]> wrote: > I hate to have another boolean for every formcomponent off every version of > the page over all the pages that are in the session. > it's a pitty that we just can't use the null value as a valid one. Because > the input from the browser can be null of course.
I understand, so I presume you did that primarily for saving space. I'm certainly too purist, but I personally would then had preferred to just use a bit of one of the already reserved flags, setting & getting the bit safely by means of a getter/setter method that would encapsulate the binary operations ( & | ...). > The modelUpToDate property is already gone. I just commeted it out for now. > will be removed completely. OK, so after that the class will be consistent. > > - I would have been pleased if you had filled the "due-to" section of > > the changes.xml doc [ ...] > i will do. > I also have to do Christian's Submit links, that also touches that area a > bit. thks :-) > I don't agree 100% because you don't think about formcomponents holding > something. I don't want to argue on that because it is at the frontier of the philosophical discussion ;-) But I definitely think on a daily use about formcomponents holding something, just as I think about Swing Components about holding something ... > i made it this: > "The Form will hold the values now in its own state until everything is > (successfully) validated to the model(s)" Good enough to me ;-) > > - Form.java: > > Strings.replaceAll(urlFor(IFormSubmitListener.class), "&", "&")); > This code doesn't have anything to do with one of the fixes. It was already > there. > But we could push it all to ComponentTag and see if that works for all > cases. > Will try to do that this weekend. Yeah. If I have some times I'll try by myself too, and do a full search of the code base for "&", "&", < .... in order to track where the introduction of html escaping in ComponentTag will need to get rid of this escaping in core & extension Components. > > - question: could you enhance the javadoc of the methods > > getCssId() and onComponentTagBody() in order to explain the purpose of > > the cssId stuff ? > cssid is something completely internal. And i hope that the current limiting > factor (that you have to render it first one time) > will be resolved some time in the further. Because i just to name the form > right so that i can call submit on it > in a event dispatch call. I understand cssid as being completely internal. But I would not offend me (nor other wicket-core readers I think) if wicket internals are documented a bit :-) ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
