GWT/Struts/Shale (or even JSF). Serious - NOT Friday!
Google Web Toolkit - GWT hi dev@ as a struts app developer (planning on using shale/jsf), i'm VERY interested in using GWT for (much of) the frontend. specifically cos i don't have to get my hands dirty writing "tags" - or well :), atleast reduce those "tags". also better debugging in a java environment so what's the status on this? r developers thinking about this? is it already in place? cheers riyaz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Struts Action Framework tagline
hi guys. back! :) just [Action] ? riyaz * [SAF 2.x] or * [Action 2.x] -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn Q: apologies if required :|
didn't get a response from [EMAIL PROTECTED], thus posting here. sorry for the inconvinience, if someone knows about this, please help. have been trying to configure my NetBeans 4.1 to use subversion (SVN) i've downloaded the svn module (beta) but can't seem to figure out how to configure it. the website (http://www.apache.org/dev/version-control.html) does not _seem_ to give how to annonymously check out data. if anybody is using this combination of software (NB41/SVN) please help riyaz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 100% declarative token management and validation; multiple values of action config "parameter"
Xinsheng [mike] Huang wrote: 1) token management. The current implemention of token management requires individual actions do themselves, i.e., "insert" token management code and logic into you action classes. That is simply not good. because it couples with yor application control code. My proposed sulotion is move the token management code out of action hirachy, instead, put in Controller and declare whether to use and how to use in struts-config.xml. Thus achive 100% declarative token management. +1 on declarative token management ( where ever it is handled :) ) 2)Validator. the validator "float" and "long" failes when the input number has trailing "f" and "l" respectively. the validwhen uses hard-coded variable name "test" to indentified the expression and make it impossible to use multiple validwhen on the same field. the validwhen fails when comapre numbers and java.util.Date or java.sql.Date, because they are compared by the string value. my last problem wit Validator was passing Date validation (with pattern -MM-dd) for values such as "1980". :) riyaz note; am not a struts committer (since it appears u're asking the struts guru's here :)) just my $0.02 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
trivial change
In this MessageTag exception can v add the name of the bundle being looked up? shud be very helpful. riyaz javax.servlet.jsp.JspException: Missing message for key "sql.success" at org.apache.struts.taglib.bean.MessageTag.doStartTag(MessageTag.java:233) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: copy properties for inheritance (Re: svn commit: r178550)
Hubert Rabago wrote: Yes, but it doesn't mean I'm not open to other ideas. In this case, I started out reading from everywhere that fields should be private, and everything should go through accessors (even subclasses). But I've been burned by that restriction LOTs of times (in some cases, I had to rebuild entire libraries to get access to the fields I needed), so I'll need some convincing. If private fields are what's best, how come every other config field is protected? i suppose a middle ground would be to keep the properties object protected but provide and use only accessor methods within struts? :) riyaz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: copy properties for inheritance (Re: svn commit: r178550)
Hubert Rabago wrote: Yes, but it doesn't mean I'm not open to other ideas. In this case, I started out reading from everywhere that fields should be private, and everything should go through accessors (even subclasses). But I've been burned by that restriction LOTs of times (in some cases, I had to rebuild entire libraries to get access to the fields I needed), so I'll need some convincing. If private fields are what's best, how come every other config field is protected? i suppose a middle ground would be to keep the properties object protected but provide and use only accessor methods within struts? :) riyaz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: copy properties for inheritance (Re: svn commit: r178550)
Hubert Rabago wrote: That's what we have now, accessors of "properties" in BaseConfig. In fact, that's the only way to access them, which goes against the convention set by most (if not all) other config objects. Other config objects declare their fields as protected, allowing custom subclasses to access those fields directly. I'll probably change "properties" in BaseConfig to follow this convention. at the moment the getProperties() returns the Map object. no necessity for the 2 accessor methods getProperty,setProperty Yes, but it doesn't mean I'm not open to other ideas. In this case, I started out reading from everywhere that fields should be private, and everything should go through accessors (even subclasses). But I've been burned by that restriction LOTs of times (in some cases, I had to rebuild entire libraries to get access to the fields I needed), so I'll need some convincing. If private fields are what's best, how come every other config field is protected? don't know about that :) but yes the "officially" (if it can be called that) seems to be to make fields private and provide accessor methods. riyaz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: copy properties for inheritance (Re: svn commit: r178550)
Hubert Rabago wrote: I'm not sure I want to forbid config subclasses from accessing their properties directly. I've come across several libraries and frameworks which used "private" all throughout and made it difficult if not impossible for me to customize certain behavior. (I'm still running into those issues with the app I inherited here in my day job.) The 'properties' field was initially declared as protected when it was only in ActionConfig. The goal was to reduce the likelihood that subclasses would be needed. Now that it's in a class that's intended to be subclassed, I wonder why it became private. Joe? there is a getProperties() method which retrieves the "properties" object my intention here was to have _all_ the accessor methods of "properties" in BaseConfig - i guess it can be a hinderance when the classes a changing rapidly as u've mentioned. i think of it as a 'cleaner' way :) classes, only ActionConfig uses "properties" and needs to change for this - not much. We also need it in FormBeanConfig. :) BaseConfig already has an "inheritProperties(BaseConfig)" method, doing just what you've outlined. This is used by subclasses when extending another config object, not to be confused with the need to "copy" another config object, which is when ActionConfig and FormBeanConfig needs access to the properties field. yes, very recently added :). again, what am trying to say is that instead of moving the "properties" object (using getProperties()) the properties can be inherited without retrieving the whole "properties" object. eg: pass the childConfig to the ParentConfig instead of the passing the parentConfig (baseConfig) to the childConfig. again, extending classes would have limited access to the properties object. it comes down to the first point u made. :) ie: > I'm not sure I want to forbid config subclasses from accessing > their properties directly. I've come across several libraries > and frameworks which used "private" all throughout and made it > difficult if not impossible for me to customize certain behavior. different ways of thinking ;) riyaz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r178550 - in /struts/core/trunk/src: share/org/apache/struts/config/ActionConfig.java share/org/apache/struts/config/BaseConfig.java share/org/apache/struts/config/FormBeanConfig.java test/org/apache/struts/config/TestActionConfig.java test/org/apache/struts/config/TestFormBeanConfig.java
just a thought.
ie, not expose the "properties" object (as it is) by the
getProperties,setProperties methods. by my last viewing of the Config
classes, only ActionConfig uses "properties" and needs to change for
this - not much.
get/setProperties can be replaced by
void inheritProperties(childConfig) {
// for each "xx" property in (parent) class
// if childConfig.getProperty("xx") == null
// copy the arbitrary property
}
imho, i think this is a good way to do this, provides separation between
BaseConfig and its extending classes
is it worth submitting a patch?
riyaz
[EMAIL PROTECTED] wrote:
Author: hrabago
Date: Wed May 25 16:35:00 2005
New Revision: 178550
URL: http://svn.apache.org/viewcvs?rev=178550&view=rev
Log:
Copy arbitrary properties of inherited form bean properties, action mapping
forwards and exception handlers.
Modified:
struts/core/trunk/src/share/org/apache/struts/config/ActionConfig.java
struts/core/trunk/src/share/org/apache/struts/config/BaseConfig.java
struts/core/trunk/src/share/org/apache/struts/config/FormBeanConfig.java
struts/core/trunk/src/test/org/apache/struts/config/TestActionConfig.java
struts/core/trunk/src/test/org/apache/struts/config/TestFormBeanConfig.java
/**
* Return the entire set of properties configured for this object.
- * At this time, this only needs to be exposed
- * to support inheritance, so choosing a conservative access modifier ("protected").
+ * At this time, this only needs to be exposed to support inheritance,
+ * so choosing a conservative access modifier ("protected").
* @return
*/
protected Properties getProperties() {
@@ -123,6 +123,15 @@
}
+/**
+ * Set the entire set of properties configured for this object.
+ * At this time, this only needs to be exposed to support inheritance,
+ * so choosing a conservative access modifier ("protected").
+ */
+protected void setProperties(Properties properties) {
+this.properties = properties;
+}
+
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: BUG FormBeanConfig.inheritFormProperties(): Implement inheritance of arbitrary config properties
Line : BeanUtils.copyProperties(prop, baseFpc) does not copy the
arbitrary properties contained in the baseFpc's FormPropertyConfigs
throwIfConfigured();
// Inherit form property configs
FormPropertyConfig[] baseFpcs = config.findFormPropertyConfigs();
for (int i = 0; i < baseFpcs.length; i++) {
FormPropertyConfig baseFpc = baseFpcs[i];
// Do we have this prop?
FormPropertyConfig prop =
this.findFormPropertyConfig(baseFpc.getName());
if (prop == null) {
// We don't have this, so let's copy it
prop = (FormPropertyConfig) RequestUtils
.applicationInstance(baseFpc.getClass().getName());
BeanUtils.copyProperties(prop, baseFpc);
this.addFormPropertyConfig(prop);
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
struts config typos that escape digester
problem: making typing mistakes in struts-config that escape the digester. saw a few comments about this. no bugs reported that i could find. some typos are only seen at runtime. eg: mistyped form name in action tag will only popup at runtime apart from normal typing errors that escape; eg: in 1.3-dev when arbitrary key/value properties come in soon, mistypes will only be seen at runtime. was wondering what do the developers think about adding a mechanism that checks this during or right after digesting struts-config? has this been discussed before? i guess some mistypes canNOT be completely removed. but things can be made easier i think. riyaz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
bug:
if (prop == null) {
// We don't have this, so let's copy it
prop = (FormPropertyConfig)RequestUtils
.applicationInstance(baseFpc.getClass().getName());
BeanUtils.copyProperties(prop, baseFpc);
this.addFormPropertyConfig(prop);
}
bug: key/value properties set in "baseFpc" is not copied to "prop"
sol1: add inline code here
sol2: add method to BaseConfig to inherit a parentConfig's properties
and call from here/above. possible other similar cases in other configs.
will submit patch, wondering which method is more suitable. ideas?
ps: i can't understand y a new FormPropertyConfig instance is created
:(. can't v just share the propConfig? it is readonly right?
riyaz
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
upload file sizes
hi guys. struts 1.3 dev validation of [minimum and] maximum file sizes are not provided even though struts will handle file uploads transparently and set a FormFile in the respective ActonForm field. this is different from setting the maxFileSize setting in ActionServlet. eg: different sized CLOB fields in db tables. is it a good idea to make an enhancement request - then upload the patch for that? thanx riyaz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tiles in 1.3 ?
hi guys. sturts dev 1.3 was wondering what happened to Tiles in 1.3 ? riyaz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Validator
hi guys. strictly not a struts question but ask as am working with struts download and compiled validator nightly build - (its been static for some time i think) problem is when validating forms in struts i get an error saying "catalog not found". and no validation is done. something to do with commons chains perhaps? am using the build to get the "extends" feature in any hints please. riyaz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DownloadAction
hi guys. sturts dev 1.3 tried out DownloadAction lastnight. it was AWESOME. great work guys. was wondering though. 1) y no getFileName() method in StreamInfo interface? i think it wud be handy to suggest to a user a file name, especially if the client user may not recognize the file type. 2) y no concrete implementation of StreamInfo that just takes ContentType and StreamInfo? i think this would be handy when objects to download are stored in databases, ie like using ResultSet.getBinaryStream() or similar methods. it would be small work to make these changes. i've done part of it already. but maybe there's good reason y they've not been provided? you guys r the experts :) riyaz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 34305] - import attribute in in
for the development core 3.0 struts is there a download available with the required jars ? the dependencies has changed a lot it seems. :) >> is there a nightly build or something available with it? > Yes, here... > http://jakarta.apache.org/commons/validator/downloads.html thanks again. will try n build this validator :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 34305] - import attribute in in
> It was done in validator about a year ago - but just hasn't been released > yet. hi. u mean that no final release has been made after the patch was submitted? or was the patch never inserted to validator? is there a nightly build or something available with it? riyaz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 34305] - import attribute in in
> You're in luck! This feature has just been added and is available in the > latest > nightly builds found on > http://svn.apache.org/builds/struts/maven/trunk/nightly/struts-core/ > > Instead of "import", we use "extends": oh great!!! i had actually written the code to do it with RuleSet SetProperty as a hack which i was gonna submit. :) any chance this will be added to form validation as well? instead of writing or copy/pasting ... just extend the in validation.xml? great work guys. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
