Ingudam Manoranjan

Thanks Remko. Something like this is exactly what I had been looking for.

I have been looking around for implementing pagination. Most of the literature point out to getting the whole records from the Database into the memory and display pagination. However I am looking at 2 level pagination, one at UI level and other at getting fix set of records from Database.

For example, I might want to show to the user only 10 records per page but would like to retrieve say about 100 records only from the database, even if the select query matches more that , say, 300 records. Getting all the 300 records at one go will be costly. So I was thinking of having another level of pagination where a parameter will specify how many records to be retrieved from the database.

I would be grateful for any help or pointers for best practices surrounding such requirement.

Thanks,
Ingudam Manoranjan

Has anyone come across any tool that given a class, it can give the call graph, both ways - referencing classes & dependent java classes?

I wanted to analyze codebase. Basically if I can get the list in a report the call graph of a java class, that will be the starting point for my analysis.

Thanks Lasse Koskela & Stan James.
I agree with you with the approach. I have done this to some extent. We already have some historical data on the effort required for "simple", "medium" & "complex" use cases. Some analysis has been done to come up with the list of use cases and classified based on the complexity.

This is some sorta informed gut feeling type of estimation I had done. However, I am not very confident. So I want to verify with some other method.

Hi Ilja Preuss ,
Reengineering, I am not sure will be the right word or not. Maybe it is plain refactoring. But here is the situation. The said product is in java & jsp codes and we want to do architectural changes.

Now I have loads of jsp & java files. I can come up with LOC per file and also come up with a a figurative complexity of each file, maybe like cyclomatic complexity [ some tools are readily available for that] and classify each file to a type complexity like again "simple", "medium", "complex".

Based on the above classification, I can put some rough figure for each type of file by doing, as Lasse Koskela was suggesting, a recoding of the file in the new architecure.

Not sure if this will be the right forum, but couldn't figure out where to post, so posting here.

We have a product which has grown over the years. We wanted to re engineer the product again & hence need to size the product and come up with the estimation. Some of the ways I can think of are:

1) Function Point estimation - which is very well for new requirements. However, identifying all the FPs of the product will take quite an effort.

2) Lines of Code - This is something I can easily find out. But how do i estimate? Basically need a corelation of the effort with the LOC.

Thanks.

Interesting.

Thanks Stan.

I agree. Testing becomes much easier with POJO.

Just wandering on the following:

Servlet gets back data from Commands.

Q1) Does Commands send back data in a common data carrier? I guess it must be so.

Servlet puts back data to Session which JSP can use to render the view.
Q1) Is such a thing configuration driven? Meaning it takes out the Configured data from the common data carrier to put back to Session.

Or
Is it that there is a seperate code to put back the data for each kind of command? In this case, I guess the Servlet will have to have that many number of Helper classes.

Hi Stan,
Would the following be considered bad design [in your opinion]? Here the Command is having a direct handle of the Session.

Browser Servlet Session JSP Command Model ------------ ------------ ------------ ------------ ------------ ------------ GET/POST +------------> execute +--------------------------------------> getData +------------> (return data) <----------------------+ forwardTo +-------------------------> get Data <------------+ (return HTML) <--------------------------------------+

What you are telling is very valid Ilja Preuss. Maybe we can still go ahead with Vinay's suggestion to some extent.

What can happen is that we have the Bean generated from the Form and passed as DTO. In between, maybe an OR mapping will take care. That way, the table and object can still coexist independently.

But , Does Encapsulation always mean something hiding ?.... and hiding from whom ?

Encapsulation is about hiding details that should not concern the client code. Your class should only have a few public interfaces that should be exposed. And only through those interfaces are the access required. So basically you have control over your class.

Java's Encapsulation and Inheritance are at logger heads in that respect. Inheritance gives access to sub classes certain privileges. But inheritance is very much required.

Thanks Vinay. I have been looking up at Expression Language of Jsp. And something that you said does strike to me and some feature is present in JSP EL as well. I will try to crystallize the idea in the next couple of days.

ov.m(d1); ov.m(d2);

When the above code is encountered, since it is over loading, it takes care of finding out the right methods based on the method signature and type.

when you do

a.getClass()

That's where polymorphism comes into picture. Based on the object that is passed, in your case, you are passing object of type D in both the cases. Hence getting the same class name.

Hope it helps.

I probably would like to take the meaning as below:

Abstraction: Just like a Abstract of a document. Gives you the gist. Similarly in Java / OOP, an abstract can probably define a type. For all i care, an java interface is also an abstraction.

Encapsulation: Just like the english definition, hide something through some accessibility rules. In Java achieved by the access modifiers applied to both the data and the behavior.

First, should a DTO be generic or specific? I don't have a strong opinion on this. Probably because I don't use DTOs very often.

Well basically there is a web layer which invokes service hosted in another server [ejb]. Hence the requirement for a DTO. However I have seen too much code going into populating the specifc DTO at the web layer and getting out the from the response DTO. Hence idea of having a generic DTO which is a universal container.

Service accepts the DTO, gives it domain [ in my case, thinking of having a constructor accepting the universal DTO]. Service use the Domain for any behavior related functionality.

And I find that my domain objects, even if they might start as simple data holders, attract behaviour quite quickly. And they do that quicker if they are not designed as generic data holders, which I prefer for that reason.

I completely agree. I think the intention should always be towards a proper domain.

Does *that* make sense?

Absolutely. :-)

Thanks Stan , Ilja for the valuable inputs. I understand the need to have different classes handling the persistence responsibility while the domain class does have the domain attributes and responsibility.