comp.lang.java.programmer http://groups-beta.google.com/group/comp.lang.java.programmer [EMAIL PROTECTED]
Today's topics: * Design pattern(s) for batch processing? - 3 messages, 2 authors http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/9d630ddc9229f91d * Function calls... - 14 messages, 10 authors http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/fffeec3e18ff1713 * RowSet vs Hibernate, JDO, etc. - 2 messages, 2 authors http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/c29f9e526c37bb1b * indexed property for array does not see my bean :-( - 3 messages, 2 authors http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/7dc882c877605dd7 * connecting to specific access database file - 2 messages, 2 authors http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/13258eb8fee18ce * [jsp]: getProperty - 1 messages, 1 author http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/6230ddcfe0818100 ============================================================================== TOPIC: Design pattern(s) for batch processing? http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/9d630ddc9229f91d ============================================================================== == 1 of 3 == Date: Sun, Dec 26 2004 8:30 am From: "Tony Morris" "fishfry" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > I'm redesigning a bunch of batch feeds for an IT org. I was wondering if > there is any literature on design patterns for batch processing, ie > command-line programs that read a record, do something, read the next > record, etc. > > Also, where besides this newsgroup can people ask design-type questions > that might not even be language-specific? Most of my Java questions seem > to be along the lines of what's the object-oriented way to do things, > rather than specific language questions. I have found a feeble, naive and malleable mind! I would like to preach to you my propagandic messages regarding OO design, and philosophies. Look out for an article next year where I offer such messages more formally, and more disguised so as to suck you in! Here are some in brief: All constructors must be declared with an access scope of 'private' - constructors violate encapsulation. All classes must be declared unsubclassable (final in the context of Java) because inheritance from non-pure virtual types (interfaces) is an evil antipattern. All references must be of a pure virtual reference type - interfacing through anything but an interface makes the Gods angry! All switch/case statements (and excessive (>4) if/else constructs) must be replaced with an implementation of the Strategy Design Pattern - procedural thought went out of fashion in kindergarten. All non-private methods of a non-private class must be static and have a return type of a pure virtual type (or value type in some contexts). -- Tony Morris http://xdweb.net/~dibblego/ == 2 of 3 == Date: Sun, Dec 26 2004 10:29 am From: Peter Sestoft "Tony Morris" <[EMAIL PROTECTED]> writes: > "fishfry" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > I'm redesigning a bunch of batch feeds for an IT org. I was wondering if > > there is any literature on design patterns for batch processing, ie > > command-line programs that read a record, do something, read the next > > record, etc. > > > > Also, where besides this newsgroup can people ask design-type questions > > that might not even be language-specific? Most of my Java questions seem > > to be along the lines of what's the object-oriented way to do things, > > rather than specific language questions. > > I have found a feeble, naive and malleable mind! > I would like to preach to you my propagandic messages regarding OO design, > and philosophies. > Look out for an article next year where I offer such messages more formally, > and more disguised so as to suck you in! > Here are some in brief: > All constructors must be declared with an access scope of 'private' - > constructors violate encapsulation. > All classes must be declared unsubclassable (final in the context of Java) > because inheritance from non-pure virtual types (interfaces) is an evil > antipattern. > All references must be of a pure virtual reference type - interfacing > through anything but an interface makes the Gods angry! > All switch/case statements (and excessive (>4) if/else constructs) must be > replaced with an implementation of the Strategy Design Pattern - procedural > thought went out of fashion in kindergarten. > All non-private methods of a non-private class must be static and have a > return type of a pure virtual type (or value type in some contexts). Sounds like a very complex way to introduce functional programming. Peter == 3 of 3 == Date: Sun, Dec 26 2004 9:45 am From: "Tony Morris" "Peter Sestoft" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > "Tony Morris" <[EMAIL PROTECTED]> writes: > > > "fishfry" <[EMAIL PROTECTED]> wrote in message > > news:[EMAIL PROTECTED] > > > I'm redesigning a bunch of batch feeds for an IT org. I was wondering if > > > there is any literature on design patterns for batch processing, ie > > > command-line programs that read a record, do something, read the next > > > record, etc. > > > > > > Also, where besides this newsgroup can people ask design-type questions > > > that might not even be language-specific? Most of my Java questions seem > > > to be along the lines of what's the object-oriented way to do things, > > > rather than specific language questions. > > > > I have found a feeble, naive and malleable mind! > > I would like to preach to you my propagandic messages regarding OO design, > > and philosophies. > > Look out for an article next year where I offer such messages more formally, > > and more disguised so as to suck you in! > > Here are some in brief: > > All constructors must be declared with an access scope of 'private' - > > constructors violate encapsulation. > > All classes must be declared unsubclassable (final in the context of Java) > > because inheritance from non-pure virtual types (interfaces) is an evil > > antipattern. > > All references must be of a pure virtual reference type - interfacing > > through anything but an interface makes the Gods angry! > > All switch/case statements (and excessive (>4) if/else constructs) must be > > replaced with an implementation of the Strategy Design Pattern - procedural > > thought went out of fashion in kindergarten. > > All non-private methods of a non-private class must be static and have a > > return type of a pure virtual type (or value type in some contexts). > > Sounds like a very complex way to introduce functional programming. > > Peter Uh, it's a pure OO way of thinking, ensuring a lot of known OO antipatterns can not be introduced, even unintentionally. It's not as I'm guessing you have interpreted it. I promise to document it formally (perhaps I should have shut up until then). -- Tony Morris http://xdweb.net/~dibblego/ ============================================================================== TOPIC: Function calls... http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/fffeec3e18ff1713 ============================================================================== == 1 of 14 == Date: Sun, Dec 26 2004 9:59 am From: "Nicky" Hi Reflection is not very fast. Another solution is to create an abstract class with a single method: public abstract class AbstractFunction { public abstract void execute(); } and to extend and implement that class for each function: public class Function1 extends AbstractFunction { public void execute() { // Code for function1 } } Hope it helps Nicky "Raymond Martineau" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > In C, it's possible to create an array of the following data structure to > associate a function call with a specific key or identifier: > > struct { > char *key; > void (*function)(); > } a[] = { { "Function1", Function1} , > { "Function2", Function2}}; > > (Or some other varient that you are comfortable with.) > > I would like to know the appropriate procedure on how to implement the > same > in Java. I would prefer to use the above system, as it can be much > quicker > to call a function by looking up the associated token in a hashtable as > opposed to writing many lines of an if/else ladder. > > The first thought that appeared in my mind would involve reflecting > classes. Checking with the API spec indicated that it should work, but > I'm > not sure that placing a large number of methods in one class is the best > solution. > > In case you're wondering, I'm using this system to interpret a language > that uses a large number of keywords (with each keyword executing its own > function.) > == 2 of 14 == Date: Sun, Dec 26 2004 9:08 am From: "Tony Morris" "Nicky" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Hi > > Reflection is not very fast. > Another solution is to create an abstract class with a single method: > > public abstract class AbstractFunction { > public abstract void execute(); > } > Abstract classes should never be used as a pure virtual type (with only abstract methods), or a concrete type (with no abstract methods). It is arguable that abstract classes should be used at all (inheritance from anything but an interface is pure evil, but that's another story for another camp fire). In the case of an attempt to use an abstract class as a pure virtual type as has been suggested, an interface is always more suited. -- Tony Morris http://xdweb.net/~dibblego/ == 3 of 14 == Date: Sun, Dec 26 2004 9:12 am From: "Tony Morris" "Tony Morris" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > "Nicky" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > Hi > > > > Reflection is not very fast. > > Another solution is to create an abstract class with a single method: > > > > public abstract class AbstractFunction { > > public abstract void execute(); > > } > > > > Abstract classes should never be used as a pure virtual type (with only > abstract methods), or a concrete type (with no abstract methods). > It is arguable that abstract classes should be used at all (inheritance from > anything but an interface is pure evil, but that's another story for another > camp fire). > > In the case of an attempt to use an abstract class as a pure virtual type as > has been suggested, an interface is always more suited. > > -- > Tony Morris > http://xdweb.net/~dibblego/ > > > It's worth nothing that a common web application framework, known as Struts (struts.apache.org last I checked), makes use of this antipattern. Struts is reknowned for its 'crustiness' for this, and many other, reasons. -- Tony Morris http://xdweb.net/~dibblego/ == 4 of 14 == Date: Sun, Dec 26 2004 9:14 am From: Lee Fesperman Raymond Martineau wrote: > > In C, it's possible to create an array of the following data structure to > associate a function call with a specific key or identifier: > > struct { > char *key; > void (*function)(); > } a[] = { { "Function1", Function1} , > { "Function2", Function2}}; > > (Or some other varient that you are comfortable with.) > > I would like to know the appropriate procedure on how to implement the same > in Java. I would prefer to use the above system, as it can be much quicker > to call a function by looking up the associated token in a hashtable as > opposed to writing many lines of an if/else ladder. > > The first thought that appeared in my mind would involve reflecting > classes. Checking with the API spec indicated that it should work, but I'm > not sure that placing a large number of methods in one class is the best > solution. > > In case you're wondering, I'm using this system to interpret a language > that uses a large number of keywords (with each keyword executing its own > function.) Reflection will work but is not the best choice here. In Java, you would normally use an object reference instead of a function pointer. The object's class would implement an interface containing the common method signature. This is quite efficient as opposed to reflection and provides additional OO capabilities vs. a function pointer. -- Lee Fesperman, FFE Software, Inc. (http://www.firstsql.com) ============================================================== * The Ultimate DBMS is here! * FirstSQL/J Object/Relational DBMS (http://www.firstsql.com) == 5 of 14 == Date: Sun, Dec 26 2004 9:19 am From: "Chris Uppal" Raymond Martineau wrote: > In case you're wondering, I'm using this system to interpret a language > that uses a large number of keywords (with each keyword executing its own > function.) For such an application, I think that the best way to go would be to use lots of little objects that all have different implementations of the same generic method. E.g (non-compliable stripped down pseudo-Java): ===== abstract class Action { void doIt(); } class Action1 extends Action { void doIt() { /* something */} } class Action2 extends Action { void doIt() { /* something */} } ... Map actions = new HashMap(); actions.add("Action1", new Action1()); actions.add("Action2", new Action2()); .... ===== In practise I would probably use anonymous inner classes rather than explicitly naming each subclass. The effect is identical, but it would help keep the source looking somewhat tighter. (But also make it harder to see what's going on, which is why I used explicit classes in the above example). -- chris == 6 of 14 == Date: Sun, Dec 26 2004 10:41 am From: Peter Sestoft [EMAIL PROTECTED] (Raymond Martineau) writes: > In C, it's possible to create an array of the following data structure to > associate a function call with a specific key or identifier: > > struct { > char *key; > void (*function)(); > } a[] = { { "Function1", Function1} , > { "Function2", Function2}}; > > (Or some other varient that you are comfortable with.) > > I would like to know the appropriate procedure on how to implement the same > in Java. I would prefer to use the above system, as it can be much quicker > to call a function by looking up the associated token in a hashtable as > opposed to writing many lines of an if/else ladder. public interface Fun { void call(); } public Pair { public final String key; public final Fun fun; public Fun(String key, Fun fun) { this.key = key; this.fun = fun; } } Pair[] a = { new Pair("Function1", new Fun() { public void call() { ... body of Function1 ... } }), new Pair("Function2", new Fun() { public void call() { ... body of Function2 ... } }), ... } If you build a hash map the array like this: Map<String,Fun> action = new HashMap<String,Fun>(); for (Pair p : a) action.put(p.key, p.fun); you get very fast execution of each instruction: action.get(keyword).invoke(); Peter == 7 of 14 == Date: Sun, Dec 26 2004 11:10 am From: Andrew McDonagh Nicky wrote: > Hi > > Reflection is not very fast. > Another solution is to create an abstract class with a single method: > > public abstract class AbstractFunction { > public abstract void execute(); > } > > and to extend and implement that class for each function: > > public class Function1 extends AbstractFunction { > public void execute() { > // Code for function1 > } > } > > Hope it helps > Nicky > > "Raymond Martineau" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > Sipped The usual name for this is 'Command pattern', however, like Tony said, the AbstractFunction class should always be an interface. So. public interface Command { void execute(); } public class KeywordCommandTwo implements Command { public void execute() { ... } } public class KeywordCommandOne implements Command { public void execute() { ... } } And this code can be used like this.... public class Foo { private Map keywordCommands = new HashMap(); public int main(String[] args) { keywordCommands.put(keywordOne, new KeywordCommandOne()); keywordCommands.put(keywordTwo, new KeywordCommandTwo()); // load each keyword from file and execute its command. for each keyword in file { KeywordCommand command = (KeywordCommand) keywordCOmmands.get(keyword); command.execute(); } } } == 8 of 14 == Date: Sun, Dec 26 2004 6:49 am From: "Ryan Stewart" "Tony Morris" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Abstract classes should never be used as a pure virtual type (with only > abstract methods), or a concrete type (with no abstract methods). > It is arguable that abstract classes should be used at all (inheritance > from > anything but an interface is pure evil, but that's another story for > another > camp fire). > I'll bite. Why never use abstract classes? == 9 of 14 == Date: Sun, Dec 26 2004 1:00 pm From: Andrew McDonagh Ryan Stewart wrote: > "Tony Morris" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > >>Abstract classes should never be used as a pure virtual type (with only >>abstract methods), or a concrete type (with no abstract methods). >>It is arguable that abstract classes should be used at all (inheritance >>from >>anything but an interface is pure evil, but that's another story for >>another >>camp fire). >> > > I'll bite. Why never use abstract classes? > > in Java, they are the 'same' as in they tell you that a given any derived/implementing class has those particular methods and also can be substituted when the interface/abstract class type is used as the referencing type. However, in java a class can only have one base class, but can implement many different interfaces at the same time. It comes down to cohesion and coupling. In C++ pure virtual abstract classes are just about the same...(ignoring the differences ;- ) == 10 of 14 == Date: Sun, Dec 26 2004 1:51 pm From: Ulf Nordlund Andrew McDonagh skrev: > Ryan Stewart wrote: > >> "Tony Morris" <[EMAIL PROTECTED]> wrote in message >> news:[EMAIL PROTECTED] >> >>> Abstract classes should never be used as a pure virtual type (with only >>> abstract methods), or a concrete type (with no abstract methods). >>> It is arguable that abstract classes should be used at all >>> (inheritance from >>> anything but an interface is pure evil, but that's another story for >>> another >>> camp fire). >>> >> >> I'll bite. Why never use abstract classes? >> > > in Java, they are the 'same' as in they tell you that a given any > derived/implementing class has those particular methods and also can be > substituted when the interface/abstract class type is used as the > referencing type. > > However, in java a class can only have one base class, but can implement > many different interfaces at the same time. > > It comes down to cohesion and coupling. > > In C++ pure virtual abstract classes are just about the same...(ignoring > the differences ;- ) > I don't understand Andrew's explanation on why abstract classes shouldn't be used... Are there any *practical* reasons why they should be avoided? (An example?) /ulf == 11 of 14 == Date: Sun, Dec 26 2004 2:18 pm From: Andrew McDonagh Take for example the JTable swing component. It displays the data contained within a TableModel. However, TableModel is an interface - not a class. This allows us to implement the same TableModel interface in any way we like, and then give our own specialized model to the Jtable. JTable does not need to know about or even guess how the tableModel is actually implemented. If JTable only ever knew about the abstract classes, then it would be assuming that ALL tableModels were of the same base type, having the same base implementation. However, most tableModels do NOT have the same base type or are implemented in the same way. Because JTable uses a generic TableModel interface, we can implement it however we like. For example, we may have a ODBC class that Implements the TableModel interface. Or a class that gets its data from XML and implements the TableModel interface so that JTable can 'see' the data. Now for convenience, Java provides a range of off-the-shelf classes which do most of the grunt work : public abstract class AbstractTableModel implements TableModel { ... } public class DefaultTableModel extends AbstracttableModel { ... } etc. But these 'assume' how most tableModels would work, but they may not be appropriate for ours. Its all about having a flexible design - anyone can implement an one or more interfaces at the same time, but all Java objects can only ever have one base class. HTH Andrew Ulf Nordlund wrote: > Andrew McDonagh skrev: > >> Ryan Stewart wrote: >> >>> "Tony Morris" <[EMAIL PROTECTED]> wrote in message >>> news:[EMAIL PROTECTED] >>> >>>> Abstract classes should never be used as a pure virtual type (with only >>>> abstract methods), or a concrete type (with no abstract methods). >>>> It is arguable that abstract classes should be used at all >>>> (inheritance from >>>> anything but an interface is pure evil, but that's another story for >>>> another >>>> camp fire). >>>> >>> >>> I'll bite. Why never use abstract classes? >>> >> >> in Java, they are the 'same' as in they tell you that a given any >> derived/implementing class has those particular methods and also can >> be substituted when the interface/abstract class type is used as the >> referencing type. >> >> However, in java a class can only have one base class, but can >> implement many different interfaces at the same time. >> >> It comes down to cohesion and coupling. >> >> In C++ pure virtual abstract classes are just about the >> same...(ignoring the differences ;- ) >> > > I don't understand Andrew's explanation on why abstract classes > shouldn't be used... Are there any *practical* reasons why they should > be avoided? (An example?) > /ulf == 12 of 14 == Date: Sun, Dec 26 2004 10:35 am From: Sudsy Andrew McDonagh wrote: > Ryan Stewart wrote: <snip> >> I'll bite. Why never use abstract classes? >> > > in Java, they are the 'same' as in they tell you that a given any > derived/implementing class has those particular methods and also can be > substituted when the interface/abstract class type is used as the > referencing type. > > However, in java a class can only have one base class, but can implement > many different interfaces at the same time. So Sun obviously made a huge mistake with the java.awt.event.XXXAdapter classes! Sorry, but I don't buy into "absolutes". The example I provided actually serves an important role in GUI development. It's a lot easier (and cleaner) to write something like this: addWindowListener( new WindowAdapter() { public void windowClosing( WindowEvent e ) { System.exit( 12 ); } } ); than have the class implement the WindowListener and have 6 out of the 7 methods be empty. YMMV == 13 of 14 == Date: Sun, Dec 26 2004 3:51 pm From: Andrew McDonagh I don't quite understand the problem you (seem) to have, maybe I'm mis-reading your words...but Sun, myself and others have no problem with adapter classes. Sun made these adapter classes available because lots of people only need to implement specific parts of the interface, not all of them. By having a single WindowListener interface it saved having to have multiple specific event listener interfaces. The adapter pattern is great for this. However, the Sun code isn't designed to reference objects by the xxxAdapter type, it references via the Interface the adapters (stub) implement. Andrew Sudsy wrote: > Andrew McDonagh wrote: > >> Ryan Stewart wrote: > > <snip> > >>> I'll bite. Why never use abstract classes? >>> >> >> in Java, they are the 'same' as in they tell you that a given any >> derived/implementing class has those particular methods and also can >> be substituted when the interface/abstract class type is used as the >> referencing type. >> >> However, in java a class can only have one base class, but can >> implement many different interfaces at the same time. > > > So Sun obviously made a huge mistake with the java.awt.event.XXXAdapter > classes! Sorry, but I don't buy into "absolutes". The example I provided > actually serves an important role in GUI development. It's a lot easier > (and cleaner) to write something like this: > > addWindowListener( new WindowAdapter() { > public void windowClosing( WindowEvent e ) { > System.exit( 12 ); > } > } ); > > than have the class implement the WindowListener and have 6 out of the > 7 methods be empty. YMMV == 14 of 14 == Date: Sun, Dec 26 2004 8:26 am From: Chris Smith Andrew McDonagh <[EMAIL PROTECTED]> wrote: > Take for example the JTable swing component. > > It displays the data contained within a TableModel. However, TableModel > is an interface - not a class. This example, of course, quickly reaches ad absurdum, as do most examples of this pseudo-truth. Where this leaves the practical world is when you start looking at specific examples: > However, most tableModels do NOT have the same base type or are > implemented in the same way. Because JTable uses a generic TableModel > interface, we can implement it however we like. For example, we may have > a ODBC class that Implements the TableModel interface. Or a class that > gets its data from XML and implements the TableModel interface so that > JTable can 'see' the data. Except, of course, that you'd never want your database access code or XML parsing code to be aware of Swing. Here's where it *does* come down to coupling. It's better for thise data-access and parsing code to provide a generic interface that's usable by anyone, rather than something specific to the Swing GUI API. As a result, you get the frequent pattern of a model adapter; that is something like: public class XMLTableModel implements TableModel { public XMLTableModel(org.w3c.dom.Document doc) { ... } ... } And, since that class has no purpose other than to adapt data to Swing's TableModel, it wouldn't naturally extend any other class and suddenly ceases to make a good example of why something might want to extend some other class and also implement TableModel. In fact, it turns out that any linking of an underlying data source with an Swing model interface is best accomplished by composition rather than inheritance. The example also extends to many other uses of interfaces. The only time it doesn't apply, in fact, is when an interface exists in the core part of the standard API (for example, java.lang) and is therefore automatically a dependent concept for any class -- an example is Comparable or Cloneable. In the end, interfaces are generally preferable for this kind of work; but the reason is more an abstract design issue than a practical need to avoid multiple inheritance. This is all considerably short of Tony's "never use abstract classes, ever", but I'm ignoring that because Tony's obviously having a bad week. -- www.designacourse.com The Easiest Way To Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation ============================================================================== TOPIC: RowSet vs Hibernate, JDO, etc. http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/c29f9e526c37bb1b ============================================================================== == 1 of 2 == Date: Sun, Dec 26 2004 11:50 am From: "Ivan" I just read "JDBC RowSet Implementations Tutorial.pdf" and something I don't understand. RowSet can do this: -connect to database -make query i.e. fill it with data and disconnect from db -can be transfered over "wire" because it implement serializable -have cursor and can scroll through data -can insert new data when is disconnected and latter can connect to db and insert that new data in db automatically If I read well, RowSet memorize which data was taken from db i.e. where was data taken from db, and automatically make update if data change? And if new data are added to disconnect RowSet with new connection to db data are automatically inserted? Did I miss something here??? Why then Hibernate, JDO, etc., when RowSet make things easier, I mean everything is simplified, specially automatic insert and update? And I think that's easy to work with RowSet and data-aware JSF and Swing/AWT/SWT component? I know Sun have RowSet implementation, do you know for other? == 2 of 2 == Date: Sun, Dec 26 2004 9:10 am From: Chris Smith Ivan <[EMAIL PROTECTED]> wrote: > RowSet can do this: > -connect to database > -make query i.e. fill it with data and disconnect from db > -can be transfered over "wire" because it implement serializable > -have cursor and can scroll through data > -can insert new data when is disconnected and latter can connect to db and > insert that new data in db automatically Yep. > Why then Hibernate, JDO, etc., when RowSet make things easier, I mean > everything is simplified, specially automatic insert and update? The two do completely different things. RowSet lives at the database level, and gives you more flexibility to interact with specific query results. All the time, though, it works in rows and colums of a single tabular data source. Hibernate and JDO allow you to work with objects and their relationships, and can store those at a higher level, defining mappings from your OO data model to the underlying relational data source. There are several types of applications people may write. You appear to be working primarily with a database application, the essence of which is to be a front-end over straight-forward data retrieval and storage. Most of your code would then be GUI and simple data access code. In those kinds of applications, it often makes sense to deal with the database as a database, for example using JDBC (and RowSet is basically an extension of JDBC). For other applications, the core of the application is in processing logic, and the use of a database is fairly incidental; in those cases, it's best to have a more natural data model to work with than rows and columns, and there are generally lots of interactions to manage between relations of the database. It would be a real pain to use a tabular model of your data, such as RowSet, in applications like this; so JDO and Hibernate (and several other alternatives as well) help allow such a developer to use an OO model of data for calculation, and then take care of the database transparently. -- www.designacourse.com The Easiest Way To Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation ============================================================================== TOPIC: indexed property for array does not see my bean :-( http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/7dc882c877605dd7 ============================================================================== == 1 of 3 == Date: Sun, Dec 26 2004 6:29 am From: "milkyway" Hello all, I have been attempting to use the Indexed Properties as defined in http://struts.apache.org/faqs/indexedprops.html I have been working on returning a list of objects to a .jsp. In other words, in the .jsp, I have something like: .... <bean:write name="bean" property="labelValue[1].label" /> except, I have created my own class (with getters and setters) as well as an indexed property (that is part of an ActionForm servelet). My problem is as follows (I will use my code for now). When I do: <bean:write name="People" property="peopleValue[1].SocSecNo" /> then I get the following message: "org.apache.jasper.JasperException: No getter method for property peopleValue[1].SocSecNo" But for my class, I do have the getters and setters: getSocSecNo and setSocSecNo. If I just do the following: <bean:write name="People" property="peopleValue[1]" then I get the data but it looks something like: SocSecNo -> 123-45-6789 LastName -> Monster FirstName -> Herman Address -> 123 Sesame Street ... and I get *no exceptions* So, it seems like it recognizes my indexed property, it seems to recognize the data I have put in but it does not seem to recognize my bean (or see it as a bean). What must I do to make it see that I have an array of beans? What do I need to do to my own class (People) to make it a bean? I am using "Exadel Strut Studio" and have tried to make the regular class a bean by implementing it as an ActionForm (I thought a bean is a bean is a bean) but it still does not work. What can I do? Kindest Regards. PS - sorry to be so long. == 2 of 3 == Date: Sun, Dec 26 2004 9:02 am From: "Ryan Stewart" "milkyway" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] [...] > <bean:write name="People" property="peopleValue[1].SocSecNo" /> then I > get the following message: > > "org.apache.jasper.JasperException: No getter method for property > peopleValue[1].SocSecNo" > > But for my class, I do have the getters and setters: getSocSecNo and > setSocSecNo. If I just do the following: > [...] <bean:write name="People" property="peopleValue[1].socSecNo" /> == 3 of 3 == Date: Sun, Dec 26 2004 9:04 am From: "Ryan Stewart" "milkyway" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Hello all, > [...] And please choose one group to post to. Stick with comp.lang.java.help for now. It is for simple issues. The .programmer group is for more advanced things. Followup set to c.l.j.h ============================================================================== TOPIC: connecting to specific access database file http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/13258eb8fee18ce ============================================================================== == 1 of 2 == Date: Sun, Dec 26 2004 7:04 am From: "ali" hi there again hope you are not getting bored from my questions first a lot of thanks to Ryan Stewart and Chris Smith for their link on my last question about how to connect my programe to access database i really learned a lot from there but still i hope there is a way to connect my programe to an specific database file so i dont have to make dns settings like making my program connect to the file labs.mdb which is in its diroctry as it is made via visual basic by datacontrol so hope there is a way to do that in java == 2 of 2 == Date: Sun, Dec 26 2004 8:42 am From: Chris Smith ali <[EMAIL PROTECTED]> wrote: > but still > > i hope there is a way to connect my programe to an specific database > file so i dont have to make dns settings Unfortunately, if you're using the ODBC bridge driver, there's no really reliable way to make the connection without defining an ODBC data source name. ISTR that you can use something like: jdbc:odbc:MS Access Database;file=c:\myfile.mdb but that assumes that the default ODBC name for a generic Access database is present and hasn't been modified. That's not necessarily a safe assumption. I'm also not sure of the attribute name, and it might be something other than "file". Also, If you take the approach above, remember that backslashes should be escaped in a string literal. I mentioned earlier that there's a free edition of MS SQL Server that has a better JDBC driver. Could you consider using that instead? -- www.designacourse.com The Easiest Way To Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation ============================================================================== TOPIC: [jsp]: getProperty http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/6230ddcfe0818100 ============================================================================== == 1 of 1 == Date: Sun, Dec 26 2004 4:28 pm From: "Marcus Reiter" Hi, I got a Bean that represents a vector containing several Beans containing several attributes (mainly Strings). How can I set / display those attributes? I asked Google, but unforunately I can't find any fitting examples. Maybe you could help. ( I am trying to solve this just by using jsp standard tags) <jsp:useBean id="BeanName" class="packageName.BeanName" scope="application"/> <jsp:setProperty name="BeanName" property="vectorName" value="10"/> <jsp:getProperty name="BeanName" property="vectorName"/> <jsp:useBean id="IncludedBeanName" class="packageName.IncludedBeanName" scope="application"/> <jsp:getProperty name="vectorName" property="IncludedBeanName"/> <jsp:getProperty name="IncludedBeanName" property="attributeName"/> However, that doesn't work. Here is the error it throws: org.apache.jasper.JasperException: Can't find a method to write property vectorNameof type 'java.util.Vector' in a bean of type 'packageName.BeanName' Here is the java code of "BeanName.java": private Vector vectorName= new Vector(); private dbConnection = new DbConnection(); public Vector getVectorName() { return this.vectorName; } public void setVectorName(int attribute) { this.vectorName= dbConnection .getBeanList(attribute); } Here is what happens in class "dbConnection.java": Vector vectorName = new Vector(); while (rs.next()) { beanName= new BeanName(); beanName.setAttribute1(rs.getInt(1)); // auslesen der Attribute beanName.setAttribute2(rs.getString(2) + " " + rs.getString(3)); beanName.setsetAttribute3(rs.getInt(4)); beanName.setAttribute5(rs.getDate(5)); beanName.setAttribute6(rs.getString(6)); beanName.setAttribute7(rs.getString(7) + " " + rs.getString(8)); vectorName .add(beanName); } Can you help? Thanks, Marcus ============================================================================== You received this message because you are subscribed to the Google Groups "comp.lang.java.programmer" group. To post to this group, send email to [EMAIL PROTECTED] or visit http://groups-beta.google.com/group/comp.lang.java.programmer To unsubscribe from this group, send email to [EMAIL PROTECTED] To change the way you get mail from this group, visit: http://groups-beta.google.com/group/comp.lang.java.programmer/subscribe To report abuse, send email explaining the problem to [EMAIL PROTECTED] ============================================================================== Google Groups: http://groups-beta.google.com
