|
|||||||||||
PREV CLASS NEXT CLASS | FRAMES NO FRAMES | ||||||||||
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |
java.lang.Object | +--org.enhydra.barracuda.A_Changes_History
The purpose of this class is to track all major changes made to the Barracuda framework. If you check changes into cvs, you must document those changes here. The list should be sorted in reverse chronological order (newer at the top).
csc_061702.1 - applied the same changes identified in sam_061602.1 to BlockIterateHandler, BTemplateGateway, and BrowserCheck.
sam_061602.1 - small change to BTemplateViewHandler contributed by
Stefan Armbruster
csc_061402.1 - Research various issues associated with EventConnectorFactory. Turns out that if you want to use it with inner class event handlers, those handlers MUST be declared as public static or you will get an instantiation exception at runtime (even though everything will compile fine at compile time). I did modify the factory to at least try getting an instance of the class when its instantiated--that way, if there are errors, they'll be caught when the servlet starts up, rather than waiting for a user to stumble into that section of code.
csc_061302.1 - Very minor tweak to DefaultViewHandler...changed the scope of the class variables from public to protected (I had opverlooked this yesterday)
jrk_061302.1 - Added support for using FileAppender's in the Log4jInit servlet which is loaded at application startup. If no custom path is provided, a default path set to WEB-INF/logs is used. A system property is set up to reference this path which is named based on the following scheme: [webapp name].log.home. So, in Baracuda's case, it would be Barracuda.log.home. This is referenced in the xml file as ${Barracuda.log.home}. More details are in the Javadoc for org.enhydra.barracuda.core.util.logging.Log4jInit.java and Barracuda's web.xml.
I also added some other Appenders that might be useful to people such as the DailyRollingFileAppenderExt and the SMTPAppender. They are not used by default, but are available. The current default appender is the FileAppender and will, by default, log to WEB-INF/logs at application startup.
Now I just have to figure out why I am getting duplicat logging statements from Log4j? I have a question out on the log4j-user email list which will, hopefully, be answered in short order.
csc_061202.1 - More work to fix the previous change. Basically, I had been setting the Cache-Control header to "public", and this was not correct. It needs to be set to "max-age=0"; this will cause IE to NOT reload the page if you go back in the browser history, but if you re-visit the URL the page will be reloaded. This is now the default behaviour in DefaultDOMWriter if you do not specify the prevent caching flag.
Now, there will be cases where we want to set max-age to a non-zero value; I modified DefaultDOMWriter to allow for this. Then, I also realized that DefaultViewHandler needs to make it easy to set this value, so I created a protected variable called maxAge which your event handler code can modify if you want to specify the number of seconds before the page is considered stale. Also, I realized that the printPretty and preventCaching vars in DefaultViewHandler should NOT be static, as we probably don't want these values to apply system wide. So I changed their scope accordingly. After testing, things seem to work better all-around now.
csc_061202.1 - Added logic to explicitly set the response headers so as to allow the browsers to cache pages (previously, we were only setting the hdrs when we DIDN'T want the browser to cache). There's a couple of resources on which this change was based:
csc_061102.1 - Updated DefaultDOMWriter to add some logging stmts
csc_060702.1 - I changed FormType's BigDecimal stuff to use the String constructor since the javadocs say that using the Double constructor is unpredicatable. Also modified to stripping out the dollar sign if its there. Added a StringUtil class (and test case) to org.enhydra.barracuda.core.util. Renamed DateUtils to DateUtil for consistency.
dbr_060702.1 - added support for BigDecimal in
org.enhydra.barracuda.core.forms.FormType.java. Code was submitted by
Diez Roggisch
jdv_060602 - apply Jason Vincents patch to Localize
We decided to modify our clean target in our build.xml file to remove all *.xmlc and all localized html files from our xmlc/resources directory. In doing so, i noticed that localized html files are created if the timestamp of them is equal to the xmlc files timestamp. They were created initially in the same second as the xmlc files, so they would be compiled again on the next build, even though neither had changed. I tweaked Localize.java to fix this (search for jdv_060602, in two locations).Jake then updated the build.xml to add new targets to cleanup localization generated .xmlc and .*ml files. Look for the "source.xmlc.clean" target.
csc_060502.1 - removed an unnecessary import stmt from org.enhydra.barracuda.core.util.dom.io.DOMFormatter. This import stmt was causing jikes compiler to fail - thanks to Franck Routier [Franck.Routier@hospvd.ch] for finding/fixing this
jdv_053102.1 - apply Jason Vincents patch to Localize2 and rename taskdef to Localize.java. Removed Localize2.java from cvs. Updated build.xml to reference Localize instead of Localize2. Verified that the newly regenerated Locaization examples still work as expected.
csc_053102.2 - improved the logging in ObjectRepositoryAssembler, added a simple test case, and moved log4j.properties to the /WEB-INF directory (previously the build was copying it to WEB-INF/classes). Q: Do we still need log4j_localize.properties and log4j_testing.properties?
csc_053102.1 - changed the logger variable in some classes back to localLogger; this prevents variable conflicts when you extend these classes (ie. in inner classes)
csc_052902.1 - added support to ObjectRepositoryAssembler for a property tag. This makes it easy to set variables (espec. static constants) at assembly time. See the object-repository.xml for an example. Right now Strings, Integers, and Booleans are supported.
csc_051302.1 - modified BlockIterateHandler so that when it renders DOM nodes it does not render closing tags for HTML elements for which closing tags are forbidden. Also added an initHandler() method.
jrk_051002.1 - I am removing the regular xmlc-2.0.1 and replacing it with xmlc-2.1-preview. This new xmlc is independent of xerces, jtidy, and gnu-regexp. Of course, those other libraries are still needed and are included here as jtidy-r7-patched and gnu-regexp-1.1.4. They are based on the newest versions of the libraries currently available (with some patches added to jtidy to make it dom3 compatible).
xmlc-2.1-preview still requires Xerces-1.x.x and I suggest using the latest Xerces-1.4.4. Xerces-2.x.x support willl come in a while, but there are too many dependencies at this time.
The one caveat with using this new version of xmlc with Xerces is that Xerces needs to have org.apache.xerces.dom.DocumentTypeImpl.java patched so that the following method:
void setOwnerDocument(CoreDocumentImpl doc) is changed to: protected void setOwnerDocument(CoreDocumentImpl doc)
xmlc-2.1-preview has one or more classes that subclass DocumentTypeImpl, override the setOwnerDocument, and make calls to super(doc). If the method is not visible to the subclass (which it isn't unless it is specifically marked as public or protected), then the JVM denies access to the method and the code bombs.
I will, temporarily, provide the modified source and binary forms of DocumentTypeImpl at ftp.visi.com/users/hoju/pub. All you need to do is drop in the new compile class into the org.apache.xerces.dom package in the Xerces jar file. Then you are set to go.
BTW, if you are using j2sdk1.4, make sure you put the Xerces jar file in the $JAVA_HOME/jre/lib/endorsed directory. Do *not* assume that the $JAVA_HOME/jre/lib/ext directory is the equivalent of this. It absolutely needs to be in the endorsed directory or you will run into some very strange behavior. Otherwise, with JDK's previous to 1.4.0, you can put the xerces jar file anywhere in your classpath for compilation and in Tomcat's $TOMCAT_HOME/common/lib directory if you are using Tomcat4.x.x.
That should be everything. This should be easier to use and more efficient than xmlc-2.0.1. More updates will continue on xmlc-2.1, but this should work great in the meantime.
Please report any bugs you find to the list promptly!
jrk_051002.1 - modified ScriptDetector... made it so prepareClientResponse(Document, ViewContext) checks the DETECT_CLIENT_SCRIPTING_ENABLED before anything and then just ignore documents that we don't yet support in actually preparing the response instead of throwing a DOMException. Probably want to re-visit this if we ever turn this back on by default to cover XHTMLDocument, WMLDocuemnt, and any other type of document that we wish to support in finding whether the browser supports scripting for that document.
Specifically, this fixes cases where an XMLDocument is passed in like in the "Hello XML World" example in the component tutorial and we were throwing an exception because we don't explicitly support any other document than HTMLDocument.
jrk_050802.1 - applying modifications to FormType.java submitted by
Chris Webb I've reorgainsed the class org.enhydra.barracuda.core.forms.FormType to be a bit more OO.
This is a drop in replacement with no side effects on any other classes. It should be a bit
more efficient as well as the nested if statement has been replaced by sub-class method calls
and there is no need to store any state about the return class type. The main benefit for this change I believe is maintainability. It should also be possible
now to add new types without changing the FormType class by sub-classing FormType and adding
new static definitions. This means that only real generic types are defined in FormType and
extensions defined somewhere else.
csc_050702.1 - modified TemplateHelper so that it will support nested iteration directives embedded within the same nodes. Cool. This was actually pretty tricky to implement, since it requires that when we hit an ITERATE_END, we not only loop back up to the starting node, but we skip all directives contained in that node until we get to nodes that pertain to the current iteration loop. Also required that when we hit an ITERATE_END, we ignore it unless it matches the current iteration context. RE-ran the test suite and everything passed muster, so I think this change is good to go (ie. I'm pretty sure it doesn't break anything).
csc_041802.1 - technically the tree is frozen, but since its not actually getting pulled until tonight, I'm checking this minor change in now. Added a getRootSource method to BaseEvent/DefaultBaseEvent...if the source is an instance of BaseEvent, it'll chain as deeply as possible to find the base event. Useful for handling hierarchical events where you want to know what the actual event fired by the client was.
csc_041702.1 - Emergency source check in to prepare for move to SourceForge. I've added some minor (but important) fixes to the component classes, mostly relating to making sure references get freed up so that objects can garbage collect properly. I've also patched the FormMap class (see previous entry below), plus I've added 3 new classes to the core.event.helper package BlockIterator, AbstractBlockIterator, and BlockIterateHandler. These are used to handle very large DOM templates; I'll have to document them in detail later.
csc_041602.1 - readded a getVals() method whioch seems to have gotten deleted from the previous revision of DefaultFormMap
jrk_041602.1 - committing patch submitted by Jefferson K. French
jrk_041502.1 - Ok, this is the update that everyone has been waiting for!
The Form Mapping overhaul. Very special thanks go to Iman Crawford
Projects/EnhydraOrg/toolsTech/Barracuda/src/org/enhydra/barracuda/core/forms/: AbstractFormValidator.java And.java DefaultFormMap.java DefaultFormValidator.java FormType.java FormValidator.java Or.java Projects/EnhydraOrg/toolsTech/Barracuda/src/org/enhydra/barracuda/core/forms/validators/: DateRangeValidator.java DateValidator.java DigitValidator.java EqualsValidator.java MaxLengthValidator.java MinLengthValidator.java NotNullValidator.java RangeValidator.java ValidTypeValidator.java
Its more consistent now. All FormValidators are supposed to validate, if the
entered value is null. This wasn't the case, so e.g. the MinLengthValidator
forced the user to enter something. The solution had been monsters like this:
new Or(new Not(new NotNullValidator()), new MinLengthValidator(10))
.
Now, every mandatory form field needs a NotNullValidator attached to it. What value is interpreted as null is also more consistent: the AbstractFormValidator now has a isNull-method.
Also, we made sure all validators validated the element.origVal. In some cases the validator would validate element.val and would cause inconsistancies when element.defaultVal was not null, but parseexceptions had occurred.
public boolean isNull(Object val, FormElement element)
Checks the nullness of the element parameter. This was to insure all validator derived from AbstractFormValidators had the same concept of nullness.
private Object mapElement(FormElement element, Object origVal, Locale loc)
Checked the type of origVal and not parse it if it is the expected type of the element parameter.
public void validate(FormElement element, FormMap map, boolean deferExceptions) throws ValidationException
Changed validation to take place on the element.origVal
instead of
public Object parse(String origVal) throws ParseException
Make sure FormType.SHORT and FormType.LONG parses values that have zeros following the decimal place.
public boolean isNull(Object val, FormElement element)
This is to encourage checking for nullness in a consistant way.
public void validateFormElement(Object val, FormElement element, boolean deferExceptions) throws ValidationException
Check for and allow null values first thing by calling the ancestor method isNull, and remove
any other null checks. Moved a call to element.getType
to happen after a null
check on the element parameter... Restructered code to check the range calling
element.getVal
if no parseexception had been raised. Also validate against val
parameter if it is of type Date.
public void validateFormElement(Object val, FormElement element, boolean deferExceptions) throws ValidationException
Check for and allow null values first thing by calling the ancestor method isNull, and remove any
other null checks. Removed code to get and parse element.origVal
, the parameter val
is the origVal Restructered code to check the range calling element.getVal if no parseexception
had been raised. Also validate against val parameter if it is of type Date.
public void validateFormElement(Object val, FormElement element, boolean deferExceptions) throws ValidationException
Check for and allow null values first thing by calling the ancestor method isNull, and remove any
other null checks. Removed code to get and parse element.origVal
, the parameter val
is the origVal
public void validateFormElement(Object val, FormElement element, boolean deferExceptions) throws ValidationException
Check for and allow null values first thing by calling the ancestor method isNull, and remove any other null checks. Check for any parseexceptions being raise, fail if there was one.
allowMultiples = true
. Needs some unit
testing code and some real testing not ready for use. Also contains a method to make a copy of an
element for the purpose of deferring exceptions.
public void validateFormElement(Object val, FormElement element, boolean deferExceptions) throws ValidationException
Check for and allow null values first thing by calling the ancestor method isNull, and remove any other null checks.
public void validateFormElement(Object val, FormElement element, boolean deferExceptions) throws ValidationException
Check for and allow null values first thing by calling the ancestor method isNull, and remove any other null checks.
public void validateFormElement(Object val, FormElement element, boolean deferExceptions) throws ValidationException
make sure to call the ancestor's isNull method to check nullness. Removed any other null checks.
public void validateFormElement(Object val, FormElement element, boolean deferExceptions) throws ValidationException
Check for and allow null values first thing by calling the ancestor method isNull, and remove any other null checks. Make sure no parseexceptions occurerd for the element parameter.
public void validateFormElement(Object val, FormElement element, boolean deferExceptions) throws ValidationException
Check for and allow null values first thing by calling the ancestor method isNull, and remove any other null checks. Comment out a call to element.getOrigVal as the parameter val is the same.
jrk_041402.1 - Somewhat major changes here, although most shouldn't change
behavior you are seeing if you are successfully running a Barracuda app currently. These changes
make Barracuda more versatile with Servlet engines using multiple classloaders. Most these
changes have to do with classloading. The main issue is that when Barracuda libs are put in a
servlet container's lib directory so that they can be accesed by all webapps running under that
container, any call to Class.forName() will end up causing a ClassNotFoundException. The reason
is that it is looking for resources in the current classloader only and not searching all classloaders
it has access to. The proper way to do this in Java2 is:
Thread.currentThread().getContextClassLoader().loadClass(String)
After adding that, I was able to run most of the Barracuda apps from the $TOMCAT_HOME/lib directory.
I still ran into a couple other errors. One was a related error in the DefaultPropertiesModel where
I was getting a MissingResourceException. The fix to that is, when calling ResourceBundle.getBundle
we need to pass in the classloader.
The last nasty error I was getting was a NullPointerException in java.util.ArrayList. This stemed from the getViews() method in BComponent not checking for null before sending an existing ArrayList into a new ArrayList constructor.
I added the null check and just retun null if "views" was null. Not sure why "views" is null, though. We will have to look for the root cause later. It only seems to happen when running Barracuda apps with Barracuda libs in $TOMCAT_HOME/lib. Never happens when running libs out of WEB-INF/lib of any given webapp???
I also updated log4j.properties loading in BCategory. Not perfect yet, but better. Still working on this....
Look for //jrk_20020414 to find changes...
UPDATE: Those using Enhydra 3.x.x will probably run into problems using
Thread.currentThread().... and must revert to using Class.forName(). This was discussed on the
list and James Carnegie
jrk_040702.1 - modified TemplateHelper to fix a bug reported by
Tim Daly
> in AbstractBComponent L495, hasViews() returns true if there are views > _or_ tempViews: > > public boolean hasViews() { > return ((views!=null && views.size()>0) || > (tempViews!=null && tempViews.size()>0)); > } > > > in BComponent L252, getViews() doesn't return any tempViews: > > public List getViews() { > return new ArrayList(views); > } > > which can lead to an IndexOutOfBoundsException in TemplateHelper L330: > > > if (!bcomp.hasViews()) { > ...; > } else { > newNode = ((View) bcomp.getViews().get(0)).getNode(); > }
jrk_040702.1 - modified HttpServletRequestWrapper to fix parameter handling
for servers like ATG Dynamo which, upon a call to getParameter(), do not always return all
parameters if the request was a post with extra parameters on the url string. Actually, this
is just an update to an existing fix to look for parameters by "parameterName=" rather than just
"parameterName" (notice the lack of the "=" sign). This just updates the functionality to match
the way servlet engines grab parameters. Patch suggested by Andras Balogh
csc_032202.1 - found and fixed a really obscure bug in TemplateHelper, that was causing parts of the template to get processed twice, which not only was extra overhead, but also caused null pointer exceptions in certain cases (ie. when the element the step child was bound too got removed and then the step child was rendered it wouldn't have a parent, thereby causing a null pointer exception when adding teh element back into the template).
The solution in this particular case was to modify TemplateHelper so that in the main render() method, it only removes child nodes and replaces them from the master template if the component we are rendering is not a step child. I added a test case to TestBTemplateRender and verified that it seems to work. Thanks to Thuong Nguyen [thuong.nguyen@theplatform.com] for coming up with a sample piece of markup that clearly illustrated the problem.
csc_031902.1 - modified HTMLTableRenderer to implement the createDefaultNode routine. This will allow you to return a BTable component from the a template model and have it automatically get associated with the proper node.
csc_031502.2 - modified DefaultViewHandler to rename logger to localLogger; modified BTemplateViewHandler to not even reference a logger (it can always use localLogger if it needs to). This name change is useful since code which uses these classes often defines its own logger classes (calling them logger)
csc_031502.1 - created a FormUtil class which contains some simple utility functions to assist in form validation
csc_031402.2 - updated the FormMap/DefaultFormMap classes with some minor modifications. First, use a static final defaultLoc throughout rather than constantly grabbing a default loc every time we map an item. Second, add 2 mapElement methods that take a key and origVal--look up the form element that matches the key and then set the value accordingly. This makes it possible to map individual elements (rather than mapping the whole shebang all at once from a request or statemap).
csc_031402.1 - very minor change to FormType so that it will correctly map Boolean types from "y" and "n", along with other strings
csc_031202.1 - AbstractBComponent - tweaked destroyCyle so that it checks to make sure children are non-null before trying to iterate through and invoke destroy cycle on them. This should fix a null pointer exception that Peter Mergaerts [PMERGAER@janbe.jnj.com] was getting on occasion
csc_030802.1 - Found and fixed a bug in AbstractBComponent; when removing al step children, need to invoke their destroyCycle() method to ensure that they correctly release references to data, allowing them to be reclaimed by system gc
csc_030602.1 - Added a WeakSession repository to the ObjectREpository class. This basically gives you a place to put things that are scoped to session but can be reclaimed by the garbage collecter as needed. Excellent place to put things like multi-page results sets; if its there, you don't have to re-query the DB, if it's not then you know you need to.
csc_025102.1 - Modified DefaultEventContext so that when persisting/restoring state, it saves Local ObjectRepository state as well across client side redirects)
csc_022102.1 - Removed GlobalRepository, and revamped ObjectRepository (both found in org.enhydra.barracuda.core.util.data). Basically, ObjectRepository now extends StateMap, and can be used to easily access common storage areas, scoped as:
The basic idea here is too make it really easy to access common storage spaces (in particular: Global, Session, and Local). So this class provides static methods for all of these. To make this integrate with Barracuda, I modified ApplicationGateway and ComponentGateway to set up the Session repository (has to pass it a ref to the req obj), and then to clean up these repositories when the request is complete.
What this means is that you can easily access session information from anywhere in your code now... simply call ObjectRepository.getSessionRepository() and proceed to put data in or take it out. Same thing for global and local.
jrk_021902.1 - Made change supplied by Stephen Peterson
jrk_021802.1 - Made changes supplied by Diez B. Roggisch
The problem is that we (and surely others as well) need support for file uploads. These come as MIME-Requests. The standard HttpServletRequest can't deal with them, so you have to use your own wrapper. Unfortunately BARRACUDA doesn't allow to install yourt own wrapper. So I made some changes to ApplicationGateway. It now doesn't create a HttpServletRequestWrapper by default. Instead a method wrap is called. This method creates either a HttpServletRequestWrapper or it invokes a RequestMapper.wrap method. The RequestMapper is a simple interface, and it can be installed by setting a class variable in ApplicationGateway.
jrk_021502.1 - Made changes supplied by Stephen Peterson. I made a some formatting changes and added contributors where appropriate.
This class associates a given event with a given event handler. This class reduces the need for the anonymous inner classes typically found in gateways. To associate an event with an event handler reduces to a single line of code:
specifyLocalEventInterests( new EventConnectorFactory( Handler.class), Event.class );
in some of my setups I kept getting a NullPointerException in DefaultView.searchForTemplates() ... I never quite found exactly what was wrong with my setup, but adding a null check on curnode at the start of searchForTemplates() took care of it. (jrk - I also added a logger.warn() line if the node is null)
csc_021502.1 - Modified all the test cases to use assertTrue() instead of assert() (assert is now a keyword in JDK 1.4)
csc_021102.3 - Fixed a bug in BComponent, whereby renderView didn't really do anything. This meant that if you used a plain-jane BComponent (ie. to control enabled/disabled), the custom renderer never got invoked. By adding this functionality into BComponent, you can now use plain BComponents to control both visibility and enabled/disabled rendering, plus, we were able to remove all the duplicated renderView methods from all of the individual components that extend from BComponent. Much much better now...
csc_021102.2 - Modified HTMLComponentRenderer so that is again sets enabled/disabled at the end of the render cycle. This was commented out at some point way back, and I can't figure out why...there's a chance that it might cause a problem if you pass back a disabled BAction component (since the component would be disabled, the HTMLComponentRenderer would remove any references to href and target; perhaps this might cause a problem when the HTMLActionRenderer tries to render next...but I can't see anything obvious in the code, so if you run into anything, let me know). This change is necessary so that you can use a plain-jane BComponent to control simple things like visibility and enabled/disabled status.
csc_021102.1 - Modified the BTemplateViewHandler so as to allow the abstract method to return either a TemplateModel or a List of TemplateModels. Before now, you could only return one. If you are extending from this class anywhere, please note that the method signature changed from singular to plural: getTemplateModels (note the 's'!)
csc_020602.1 - removed all references to log4j stuff in the org.enhydra.barracuda.taskdefs package. Basically, if you need loggin here, use that provided by Ant. This eliminates the need for log4j_localize.properties to be in your classes directory (which was a major pain in the butt for projects that were simply using Barracuda)
csc_020502.1 - added a new GenerateSSIs taskdef. This taskdef is primarily useful if you use ssi based mockups, when you want to edit your mockups in a single HTML file and then have pieces of it automatically written out to .ssi files. The taskdef will parse a given file (or fileset) looking for html comments that look like this (where 'foo' can be the name of any ssi file):
...
When the taskdef sees these tags it will write the contents to the target ssi file IFF the source file is newer than the ssi file or force="true". For complete details, see the source comments.
csc_020202.1 - added a NameSpace, ObjectRepository, and GlobalObjectRepository classes to org.enhydra.barracuda.core.util. These classes are useful for establishing a common storage facility, where commonly used resources (ie. datasource) can be placed. Also created an ObjectRepositoryAssembler which can be used to automatically insert items into the default ObjectRepository at startup (the assembler class implements HttpServlet, and can be pointed at a file like /WEB-INF/object-repository.xml) to automatically set up items in the OR when the servlet starts. Also made a few minor improvements to miscellaneous classes.
csc_013102.1 - added several methods to HttpServletRequestWrapper to comply with Servlet 2.3 spec. Upgraded the servlet.jar included in WEB-INF/ant/lib/ to use the new servlet 2.3 jar.
csc_013002.1 - Couple of significant changes.
jrk - Overhauled ScriptDetector.java and ScriptingCheck.js to fix bugs where mailto: and javascript: href values were improperly getting $csjs and $u parameters added to them. Also fixed a bug were hash values on URL's were not working with the scripting check because we were indiscriminately appending the scripting flags where, in order for a hash to work to link to a particular anchor in a document, the hash value needs to be the last item on the URL string.
I also enhanced the Javadoc comments in ScriptDetector removed a lot of the old code that didn't make sense anymore. In addition, I modified prepareClientResp so that it is overloaded rather than using instanceof all the time to check for the type of document we are dealing with. This provides compile-time checking rather than running into errors at runtime. I left in a version of prepareClientResp that takes a generic Document and uses instanceof for backward compatibility but I strongly recommend using the more specific HTMLDocument version and other versions (when they become supported).
The next thing to do is to create an "Assume Scripting Enabled" mode where no scripting check is run, but Barracuda will still think the client supports scripting.
dbr_012202.1 - Applied a patch from Diez B. Roggisch [diez.roggisch@artnology.com] that provides BAction setParam with support for String[] so both types of request parameters are supported now.
dbr_122801.1 - Applied patches from Diez B. Roggisch [diez.roggisch@artnology.com] that fixed bugs in both the DigitValidator and the DateValidator where they wouldn't validate if the desired FormType wasn't a String.
csc_011902.1 - Added back in UserReport.properties and UserReport_es.properties...these somehow got removed from cvs. I restored these files from the Barracuda 1.0.1 zip, and tested that the CompTest3 example works again now...Thanks to Jacob kjome [apu@mediaone.net] for catching this.
dbr_011602.1 - Applied a patch from Diez B. Roggisch [diez.roggisch@artnology.com] that expands the FormMap interface to optionally take a locale when mapping; if none is passed the default locale will be used.
jdv_121201 - Applied a patch to Localize2 from Jason Vinson [jason.vinson@mindspring.com]. This patch basically adds support for two additional taskdef parameters: masterlocalefile and masterlocaledire. If these parameters are present, Localize2 will perform all localization out of these master files, rather than looking for individual property files on a per-template basis.
As an example of this, if you wanted to localize an app and store all of text in a common directory (ie. ./Locales), using a file naming convention of MasterProps.properties, MasterProps_en.properties, MasterProps_sa.properties, etc, then you would modify your ant build.xml's invocation of Localize to pass two additional parameters, like this:
masterlocaledir="./Locales"
masterlocalefile="MasterProps"
csc_121201.1 - Fixed a bug in HTMLTextRenderer and XMLTextRenderer...only try and set the text value if text is non-null. Checked the link renderers, and found that this fix had already been applied there.
csc_112901.2 - Fixed a bug in ScriptDetector, where we weren't handling the Area element in the anchors section. Also modified BarracudaConfig to call ScriptDetector, since its not extending DefaultViewHandler.
csc_112901.1 - Fixed a bug in CopyAndReplace. Basically, if you are using it to include ssi's, you _don't_ want to copy those ssi's across too (or they get replace run on them twice, once as their own file, and then again after they've been included...this causes problems. SO...modified the build.xml to not copy across ssi files, and then modified the CopyAndReplace taskdef so that if the include file is not found it'll look in the src dir.
After updating from cvs, you MUST delete any *.ssi files which are left in src\org\enhydra\barracuda\config\xmlc.
csc_112801.1 - Created a new Localize2 taskdef (which will eventually replace Localize, once we've had a chance to test it further) and updated build.xml to use this. This new taskdef solves the issues described here: detailed here.
csc_111601.1 - Start reworking the Localize taskdef so as not to need XMLC. This solves a problem which is detailed here.
The first step was to modify the CopyAndReplace taskdef so that it can (optionally) resolve SSIs. The default is false; so if you want it to do this you will need to set the parameter accordingly (see Barracuda's build.xml for examples)
csc_110501.1 - Fix a problem that was introduced with the csc_103101.1 fix. Basically, what we were doing is creating a slightly more complex piece of markup (ie. clone the current node, then add an anchor element into it) and then returning that. The problem is that when template helper goes and automatically creates a view, it does it on the outermost node (in the case of CompEx7, this is a element, which is not valid for a link to be bound to). So the problem is that when we create a more complex piece of markup the component sometimes needs to be bound to an element that is buried down inside the node created. TemplateHelper has no idea how to find the right piece to bind it properly.
The real solution here is to modify createDefaultNode() so as to pass in a reference to the component; this then allows the code that creates the default node to optionally associate the component with the right element in the view then and there (meaning TemplateHelper won't have to do that step). Of course, if the code that creates the default node _doesnt_ create a default view, template helper will fall back to the previous approach, which is simply to create a view on the outermost node returned.
Note that there is a larger issue here which still hasn't been fixed. When the createDefaultNode returns a node with children (HTMLLinkRenderer is an example) wherein it added a view onto the part of that markup, a BTemplate delegate gets created on the nodes _after_ the delegate, but before its rendered. What this means is that even though the delegate component renders properly, the BTemplate render wipes out what was there (since the master template snapshot is taken at the time the view is created, rather than right before the component renders). This whole thing is very complex. The real solution is to revamp the way the views are generated (as described here: http://barracuda.enhydra.org/project/mailingLists/barracuda/msg02326.html) However, I don't have time to implement this right now, so I inserted a temporary fix instead: if the createDefaultNode() method adds a view, the BTemplate delegates will not be created. This isn't ideal, but it works for now.
csc_110201.1 - Added a notion of RenderStrategy, defined in org.enhydra.barracuda.core.comp.renderer.RenderStrategy as either SCRIPT_AS_NEEDED or NEVER_SCRIPT. Strategies can be set on a per-component basis; if the strategy is null, it is obtained from the component's parent; if the root component's strategy is null, it defaults to DEFAULT_RENDER_STRATEGY.
The basic idea here is that sometimes even though a client may have scripting enabled, a developer may still not want the components to render using scripting. All the developer has to do is set a component's render strategy (either at the individual component level, at the root component level, or at the default setting level in RenderStrategy). When a component renderer wishes to make use of Javascript, it must not only check to see that Javascript is enabled, but also that the component's render strategy allows for it.
Note that right now the only renderer that really uses scripting is HTMLActionRenderer. Also note that this change does NOT apply to HTMLScriptRenderer or HTMLScriptResourceRenderer...these renderers MUST always render, regardless of whether or not the client supports scripting (see notes therein for details)
csc_103101.1 - Fix a bug in HTMLLinkRenderer; when it was trying to create a default node, if the type was not ,