Hi, to all; I'm using adf for about 5 or 6 years, (since uix);
Some days ago, I find myself felling guilty to create one more task-flow or to post an binding-method call, because it will create more binding's xml files;
Really, the number of xml ( or xml based ) files, rise significantly;
How to deal with it ?
There are some kind of methodology to make an decision like :
To choose, post an (eg. executewithparams) method inside Task-Flow
or To Write actionEvents ( or valueChangeEvents ) whose use the same pageBinding file saving the application one (or many xml) files;
Not a general answer but a hint speciifc for your example. If you want
to have method binding calls use the same page def as some page within
the task flow, you can change the mapping in DataBindings.cpx:
(nnd move the binding created to EmployeesPageDef).
Steven.
Marcos Ortega wrote:
Hi, to all;
I'm using adf for about 5 or 6 years, (since uix);
Some days ago, I find myself felling guilty to create one
more task-flow or to post an binding-method call, because it will
create more binding's xml files;
Really, the number of xml ( or xml based ) files, rise
significantly;
How to deal with it ?
There are some kind of methodology to make an decision
like :
To choose, post an (eg. executewithparams) method inside
Task-Flow
or
To Write actionEvents ( or valueChangeEvents ) whose use
the same pageBinding file saving the application one (or many xml)
files;
Steven Davelaar| Technology Director | Oracle Consulting
Tel +31 30 669 8113 | Fax +31 30 669 9966
Oracle Nederland BV | Rijnzathe 6,
3454 PV De Meern, The Netherlands
PO Box 147, 3454 ZJ De Meern,The Netherlands | KvK nr. 30096087
When I first started with this stuff, I too was amazed at all the
files, most of them very short - a page or less. It bothered me - I
was used to big COBOL or C programs that were thousands of lines long,
but only one file. Even with PL/SQL, I would put an entire
application in six or seven packages, meaning twelve to fourteen
files. Each package gets a file and each package body gets a file. A
package might contain a few dozen functions or procedures.
The many files used in a typical JEE application would be a major
problem for me if I were using the source code editors of years past.
But with a good IDE like JDeveloper, all of these files are managed
for me by the IDE. Many of them are even created by the IDE, and I
sometimes don't even have to look at them. If I delete something, the
IDE is able to make sure that I'm not breaking some other code that
uses it. If I am searching for something, the IDE can search all the
files in my project or application.
In short, as long as JDeveloper is managing all these XML and Java
source files for me, I don't worry about it any more.
On Aug 20, 12:50 am, Marcos Ortega <mar...@santoandrea.com.br> wrote:
> Hi, to all;
> I'm using adf for about 5 or 6 years, (since uix);
> Some days ago, I find myself felling guilty to create one more
> task-flow or to post an binding-method call, because it will create more
> binding's xml files;
> Really, the number of xml ( or xml based ) files, rise significantly;
> How to deal with it ?
> There are some kind of methodology to make an decision like :
> To choose, post an (eg. executewithparams) method inside Task-Flow
> or
> To Write actionEvents ( or valueChangeEvents ) whose use the same
> pageBinding file saving the application one (or many xml) files;
It's indead true that you can manage the files visually in Jdeveloper,
without needing to get into coding these files yourself but ... what
about refactoring or versioning these files?
For example, you want to redefine your EO's attribute names or your
view object's name, than this refactoring needs to be cascaded into
the pageDefinition files as well.
The same goes when your updating the implementation files of your view
object, your adding methods or updating your method signature, then
these changes need to be reflected inside each configuration file that
references this VO.
That isn't the case for all updates or changes you're making, which
can augment the frustration of the team.
For example, attributes need to be added to the EO and the VO,
sometimes the files then get updated incorrectly, existing attributes
are created again inside the configuration files, which will throw
compiler errors. The developers then need to change these files
themselves, ...
Sometimes you still need to resort to coding ... to workaround some
issues in regards to refactoring or updates or changes that were made
during the development lifecycle.
When working on ADF projects I always tell the development team to
keep track of these issues, so they can be tracked and solved by the
Oracle development team. When developers are frustrated with issues or
problems using an IDE or framework, the community needs to be able to
know the issues so they can be solved. I think that's a responsibility
to pick up in every team, during every project, for every framework or
IDE you're using, so you can see the tools and frameworks growing and
augmenting in functionality as well for end users as for developers.
Kind regards,
Nathalie
On Aug 25, 3:38 pm, John Flack <JCFl...@excite.com> wrote:
> When I first started with this stuff, I too was amazed at all the
> files, most of them very short - a page or less. It bothered me - I
> was used to big COBOL or C programs that were thousands of lines long,
> but only one file. Even with PL/SQL, I would put an entire
> application in six or seven packages, meaning twelve to fourteen
> files. Each package gets a file and each package body gets a file. A
> package might contain a few dozen functions or procedures.
> The many files used in a typical JEE application would be a major
> problem for me if I were using the source code editors of years past.
> But with a good IDE like JDeveloper, all of these files are managed
> for me by the IDE. Many of them are even created by the IDE, and I
> sometimes don't even have to look at them. If I delete something, the
> IDE is able to make sure that I'm not breaking some other code that
> uses it. If I am searching for something, the IDE can search all the
> files in my project or application.
> In short, as long as JDeveloper is managing all these XML and Java
> source files for me, I don't worry about it any more.
> On Aug 20, 12:50 am, Marcos Ortega <mar...@santoandrea.com.br> wrote:
> > Hi, to all;
> > I'm using adf for about 5 or 6 years, (since uix);
> > Some days ago, I find myself felling guilty to create one more
> > task-flow or to post an binding-method call, because it will create more
> > binding's xml files;
> > Really, the number of xml ( or xml based ) files, rise significantly;
> > How to deal with it ?
> > There are some kind of methodology to make an decision like :
> > To choose, post an (eg. executewithparams) method inside Task-Flow
> > or
> > To Write actionEvents ( or valueChangeEvents ) whose use the same
> > pageBinding file saving the application one (or many xml) files;
I agree, even with small applications the number of BC's increases rapidly.
Good organization is essential and no fear of refactoring. Although, most of
the time it is handled quite well, you always have to be careful.
In addition, it is also extremely important that renaming, moving and
deletes are propagated to the source control system. We use mainly
subversion and most of the time, we use an external tool, like Tortoise, for
the main interaction with the subversion server because it's much more
functional.
It really bothers me that the subversion extension is still not available
for the latest, 1.6, subversion version. For 10g, that is still used
heavily, it is an even older, 1.4, version.
Fortunately, you can update it manually, but still.... :-(
Ciao
Aino
On Tue, Aug 25, 2009 at 4:29 PM, Nathalie Roman <liekero...@gmail.com>wrote:
> It's indead true that you can manage the files visually in Jdeveloper,
> without needing to get into coding these files yourself but ... what
> about refactoring or versioning these files?
> For example, you want to redefine your EO's attribute names or your
> view object's name, than this refactoring needs to be cascaded into
> the pageDefinition files as well.
> The same goes when your updating the implementation files of your view
> object, your adding methods or updating your method signature, then
> these changes need to be reflected inside each configuration file that
> references this VO.
> That isn't the case for all updates or changes you're making, which
> can augment the frustration of the team.
> For example, attributes need to be added to the EO and the VO,
> sometimes the files then get updated incorrectly, existing attributes
> are created again inside the configuration files, which will throw
> compiler errors. The developers then need to change these files
> themselves, ...
> Sometimes you still need to resort to coding ... to workaround some
> issues in regards to refactoring or updates or changes that were made
> during the development lifecycle.
> When working on ADF projects I always tell the development team to
> keep track of these issues, so they can be tracked and solved by the
> Oracle development team. When developers are frustrated with issues or
> problems using an IDE or framework, the community needs to be able to
> know the issues so they can be solved. I think that's a responsibility
> to pick up in every team, during every project, for every framework or
> IDE you're using, so you can see the tools and frameworks growing and
> augmenting in functionality as well for end users as for developers.
> Kind regards,
> Nathalie
> On Aug 25, 3:38 pm, John Flack <JCFl...@excite.com> wrote:
> > When I first started with this stuff, I too was amazed at all the
> > files, most of them very short - a page or less. It bothered me - I
> > was used to big COBOL or C programs that were thousands of lines long,
> > but only one file. Even with PL/SQL, I would put an entire
> > application in six or seven packages, meaning twelve to fourteen
> > files. Each package gets a file and each package body gets a file. A
> > package might contain a few dozen functions or procedures.
> > The many files used in a typical JEE application would be a major
> > problem for me if I were using the source code editors of years past.
> > But with a good IDE like JDeveloper, all of these files are managed
> > for me by the IDE. Many of them are even created by the IDE, and I
> > sometimes don't even have to look at them. If I delete something, the
> > IDE is able to make sure that I'm not breaking some other code that
> > uses it. If I am searching for something, the IDE can search all the
> > files in my project or application.
> > In short, as long as JDeveloper is managing all these XML and Java
> > source files for me, I don't worry about it any more.
> > On Aug 20, 12:50 am, Marcos Ortega <mar...@santoandrea.com.br> wrote:
> > > Hi, to all;
> > > I'm using adf for about 5 or 6 years, (since uix);
> > > Some days ago, I find myself felling guilty to create one more
> > > task-flow or to post an binding-method call, because it will create
> more
> > > binding's xml files;
> > > Really, the number of xml ( or xml based ) files, rise
> significantly;
> > > How to deal with it ?
> > > There are some kind of methodology to make an decision like :
> > > To choose, post an (eg. executewithparams) method inside
> Task-Flow
> > > or
> > > To Write actionEvents ( or valueChangeEvents ) whose use the
> same
> > > pageBinding file saving the application one (or many xml) files;
As long as you know the purpose of each xml files, it's not a big
deal. Even, I used to confuse initially but I am okay now. I am very
comfortable. To easily understand each of the xml files, create a
fusion web application. Create a web service or VO object, create a
data control and add a jsf page and then use the data control in this
page. Now, go to file explore open the xml files in view controller
and model one by one. Look at the source, you can easily understand
about it and also you can learn how things works here.
On Aug 19, 11:50 pm, Marcos Ortega <mar...@santoandrea.com.br> wrote:
> Hi, to all;
> I'm using adf for about 5 or 6 years, (since uix);
> Some days ago, I find myself felling guilty to create one more
> task-flow or to post an binding-method call, because it will create more
> binding's xml files;
> Really, the number of xml ( or xml based ) files, rise significantly;
> How to deal with it ?
> There are some kind of methodology to make an decision like :
> To choose, post an (eg. executewithparams) method inside Task-Flow
> or
> To Write actionEvents ( or valueChangeEvents ) whose use the same
> pageBinding file saving the application one (or many xml) files;
On Aug 25, 4:38 pm, John Flack <JCFl...@excite.com> wrote:
> But with a good IDE like JDeveloper, all of these files are managed
> for me by the IDE. Many of them are even created by the IDE, and I
> sometimes don't even have to look at them. If I delete something, the
> IDE is able to make sure that I'm not breaking some other code that
> uses it. If I am searching for something, the IDE can search all the
> files in my project or application.
> In short, as long as JDeveloper is managing all these XML and Java
> source files for me, I don't worry about it any more.
Hi John,
Indeed, JDeveloper is managing the application without you being
needed to know to much about the physical structure of the application
files.
But in practice sometimes it happens that you are required to
understand every detail. Some of my recent experiences on that matter:
1. We often have have conflicts in SVN in some 'hot' configuration
files. Obviously you need to understand the file contents in order to
fix the conflicts.
2. Few weeks ago I had to move a set of EO's, VO's and AM's from one
Business Project into another. Simply because they have been
misplaced. This required a lot of manual changes into the code.
3. Last week we have encountered a strange JDeveloper bug (http://
andrejusb.blogspot.com/2009/09/propertynotfoundexception-in-
query.html). Simply, JDeveloper didn't properly cleaned the code when
a return attribute was removed from an LOV. To solve it, it was
required to manually remove some xml tags from the VO.
Therefore, I would say that there is no way out of understanding
what's happening behind JDeveloper, even if JDeveloper is a great
tool.
Nathalie -
Your comment about re-factoring just hit home. I've got an
experimental project going right now, and the experiment wasn't going
well so I am about to do a major re-factoring and try a very different
direction. To some extent, the IDE is still helping me. For
instance, I just deleted a class, and JDeveloper offered to "Delete
Safely". It then showed me all my files where that class was being
used. On the other hand, I still had to remove the references to the
defunct class manually. I also wanted to delete some attributes from
an Entity Object, and JDeveloper wouldn't let me until I had first
deleted the corresponding attributes from the View Object.
I'm not sure how much more the IDE can do to help, though - I'd still
want to control what gets deleted and what re-written.
Source control is also VERY important when you have so many files.
I'm using ClearCase, and JDeveloper tends to preemptively check out
many more files than I actually change, especially when I change an
Application Module. I either have to Undo checkout of any file I
didn't change, or let ClearCase check in copies that are identical to
the previous version. I've tended to do the Undo - a big PIA, but I
think I should stop that - it wastes my time. So what if the two
versions are identical?
Thanks for sharing your experiences with the community and shedding
light on the problems you're facing today.
I was thinking ... maybe we should document the refactoring-issues, so
we can go through each of these items at OOW and discuss how you can
best handle these problems.
In other words, if everyone that's facing this problem today could
document the following information:
1) Jdeveloper Version
2) Application Architecture (ADF Faces + BC; JSF + BC; ADF Faces +
JPA; JSF + JPA, JSP + BC; JSP + JPA)
3) Issues in regards to refactoring occur at configuration level (eg.
xml config files), business level, presentation level.
For example:
I've refactored my database table and renamed 2 attributes and removed
one. The renamed attributes are updated in the view object, but the
configuration file of the view object and pageDefinition files aren't
refactored. I need to manually change these files.
=> Level of issues: configuration and presentation level.
=> With this information we can document the issues we're having today
and work-out best practices, guidelines together with the Oracle
Product Management and Development team.
Do you think this could help us in the future?
Kind regards,
nathalie
On Sep 21, 12:55 am, John Flack <JCFl...@excite.com> wrote:
> Nathalie -
> Your comment about re-factoring just hit home. I've got an
> experimental project going right now, and the experiment wasn't going
> well so I am about to do a major re-factoring and try a very different
> direction. To some extent, the IDE is still helping me. For
> instance, I just deleted a class, and JDeveloper offered to "Delete
> Safely". It then showed me all my files where that class was being
> used. On the other hand, I still had to remove the references to the
> defunct class manually. I also wanted to delete some attributes from
> an Entity Object, and JDeveloper wouldn't let me until I had first
> deleted the corresponding attributes from the View Object.
> I'm not sure how much more the IDE can do to help, though - I'd still
> want to control what gets deleted and what re-written.
> Source control is also VERY important when you have so many files.
> I'm using ClearCase, and JDeveloper tends to preemptively check out
> many more files than I actually change, especially when I change an
> Application Module. I either have to Undo checkout of any file I
> didn't change, or let ClearCase check in copies that are identical to
> the previous version. I've tended to do the Undo - a big PIA, but I
> think I should stop that - it wastes my time. So what if the two
> versions are identical?
JDeveloper will support 1.6 in our next release, as with all tools we are encumbered by both our release schedules and the corresponding release of the SVNKit
I'm also interested in (as you might imagine)
"for the main interaction with the subversion server because it's much more functional."
> I agree, even with small applications the number of BC's increases > rapidly. Good organization is essential and no fear of refactoring. > Although, most of the time it is handled quite well, you always have > to be careful.
> In addition, it is also extremely important that renaming, moving and > deletes are propagated to the source control system. We use mainly > subversion and most of the time, we use an external tool, like > Tortoise, for the main interaction with the subversion server because > it's much more functional.
> It really bothers me that the subversion extension is still not > available for the latest, 1.6, subversion version. For 10g, that is > still used heavily, it is an even older, 1.4, version.
> Fortunately, you can update it manually, but still.... :-(
> Ciao
> Aino
> On Tue, Aug 25, 2009 at 4:29 PM, Nathalie Roman <liekero...@gmail.com > <mailto:liekero...@gmail.com>> wrote:
> Hi John,
> It's indead true that you can manage the files visually in Jdeveloper,
> without needing to get into coding these files yourself but ... what
> about refactoring or versioning these files?
> For example, you want to redefine your EO's attribute names or your
> view object's name, than this refactoring needs to be cascaded into
> the pageDefinition files as well.
> The same goes when your updating the implementation files of your view
> object, your adding methods or updating your method signature, then
> these changes need to be reflected inside each configuration file that
> references this VO.
> That isn't the case for all updates or changes you're making, which
> can augment the frustration of the team.
> For example, attributes need to be added to the EO and the VO,
> sometimes the files then get updated incorrectly, existing attributes
> are created again inside the configuration files, which will throw
> compiler errors. The developers then need to change these files
> themselves, ...
> Sometimes you still need to resort to coding ... to workaround some
> issues in regards to refactoring or updates or changes that were made
> during the development lifecycle.
> When working on ADF projects I always tell the development team to
> keep track of these issues, so they can be tracked and solved by the
> Oracle development team. When developers are frustrated with issues or
> problems using an IDE or framework, the community needs to be able to
> know the issues so they can be solved. I think that's a responsibility
> to pick up in every team, during every project, for every framework or
> IDE you're using, so you can see the tools and frameworks growing and
> augmenting in functionality as well for end users as for developers.
> Kind regards,
> Nathalie
> On Aug 25, 3:38 pm, John Flack <JCFl...@excite.com
> <mailto:JCFl...@excite.com>> wrote:
> > When I first started with this stuff, I too was amazed at all the
> > files, most of them very short - a page or less. It bothered me - I
> > was used to big COBOL or C programs that were thousands of lines
> long,
> > but only one file. Even with PL/SQL, I would put an entire
> > application in six or seven packages, meaning twelve to fourteen
> > files. Each package gets a file and each package body gets a
> file. A
> > package might contain a few dozen functions or procedures.
> > The many files used in a typical JEE application would be a major
> > problem for me if I were using the source code editors of years
> past.
> > But with a good IDE like JDeveloper, all of these files are managed
> > for me by the IDE. Many of them are even created by the IDE, and I
> > sometimes don't even have to look at them. If I delete
> something, the
> > IDE is able to make sure that I'm not breaking some other code that
> > uses it. If I am searching for something, the IDE can search
> all the
> > files in my project or application.
> > In short, as long as JDeveloper is managing all these XML and Java
> > source files for me, I don't worry about it any more.
> > On Aug 20, 12:50 am, Marcos Ortega <mar...@santoandrea.com.br
> <mailto:mar...@santoandrea.com.br>> wrote:
> > > Hi, to all;
> > > I'm using adf for about 5 or 6 years, (since uix);
> > > Some days ago, I find myself felling guilty to create
> one more
> > > task-flow or to post an binding-method call, because it will
> create more
> > > binding's xml files;
> > > Really, the number of xml ( or xml based ) files, rise
> significantly;
> > > How to deal with it ?
> > > There are some kind of methodology to make an decision
> like :
> > > To choose, post an (eg. executewithparams) method
> inside Task-Flow
> > > or
> > > To Write actionEvents ( or valueChangeEvents ) whose
> use the same
> > > pageBinding file saving the application one (or many xml) files;
> > > What about the naming patterns?
> > > Thanks for all;
> > > Marcos Ortega
> > > Analista de Sistemas
> > > Campo Grande - MShttp://www.santoandrea.com.br- Hide quoted
> text -
In the next release of JDeveloper you will see great improvements to preemptive file check out. This is something that our Fusion developers also identified and has been worked on.
In general, and this goes for all aspects of JDeveloper and all users, if you have problems such as this I would urge you to log support calls so we can ensure that we catch your use cases on bugs. I realise that 1. you may not have support, 2. it takes time but it is effective.
> Nathalie -
> Your comment about re-factoring just hit home. I've got an
> experimental project going right now, and the experiment wasn't going
> well so I am about to do a major re-factoring and try a very different
> direction. To some extent, the IDE is still helping me. For
> instance, I just deleted a class, and JDeveloper offered to "Delete
> Safely". It then showed me all my files where that class was being
> used. On the other hand, I still had to remove the references to the
> defunct class manually. I also wanted to delete some attributes from
> an Entity Object, and JDeveloper wouldn't let me until I had first
> deleted the corresponding attributes from the View Object.
> I'm not sure how much more the IDE can do to help, though - I'd still
> want to control what gets deleted and what re-written.
> Source control is also VERY important when you have so many files.
> I'm using ClearCase, and JDeveloper tends to preemptively check out
> many more files than I actually change, especially when I change an
> Application Module. I either have to Undo checkout of any file I
> didn't change, or let ClearCase check in copies that are identical to
> the previous version. I've tended to do the Undo - a big PIA, but I
> think I should stop that - it wastes my time. So what if the two
> versions are identical?
I'm glad to hear that the preemptive checkout is being curbed.
Sometimes, I'm not sure if an annoyance like this is really a bug - it
doesn't really hurt anything, in fact, it's trying to be helpful. But
it IS annoying.
I hope the changes for the next version of JDeveloper help someone,
but they won't help me yet. I'm starting to evaluate a possible shift
from ClearCase to Subversion, and in Subversion, it doesn't look like
you normally "check out" files like you do in ClearCase. I'm also
still using JDeveloper 10.1.3.5, and will not be switching to
JDeveloper 11g for production work for a while (it may be as long as a
year) because we aren't ready to switch from the Apache/OC4J based
application server to the WebLogic based one.
On Sep 21, 7:01 am, susan duncan <susan.dun...@oracle.com> wrote:
> In the next release of JDeveloper you will see great improvements to
> preemptive file check out. This is something that our Fusion developers
> also identified and has been worked on.
> In general, and this goes for all aspects of JDeveloper and all users,
> if you have problems such as this I would urge you to log support calls
> so we can ensure that we catch your use cases on bugs. I realise that 1.
> you may not have support, 2. it takes time but it is effective.
> rgds
> Susan
> On 20/09/2009 23:55, John Flack wrote:
> > Nathalie -
> > Your comment about re-factoring just hit home. I've got an
> > experimental project going right now, and the experiment wasn't going
> > well so I am about to do a major re-factoring and try a very different
> > direction. To some extent, the IDE is still helping me. For
> > instance, I just deleted a class, and JDeveloper offered to "Delete
> > Safely". It then showed me all my files where that class was being
> > used. On the other hand, I still had to remove the references to the
> > defunct class manually. I also wanted to delete some attributes from
> > an Entity Object, and JDeveloper wouldn't let me until I had first
> > deleted the corresponding attributes from the View Object.
> > I'm not sure how much more the IDE can do to help, though - I'd still
> > want to control what gets deleted and what re-written.
> > Source control is also VERY important when you have so many files.
> > I'm using ClearCase, and JDeveloper tends to preemptively check out
> > many more files than I actually change, especially when I change an
> > Application Module. I either have to Undo checkout of any file I
> > didn't change, or let ClearCase check in copies that are identical to
> > the previous version. I've tended to do the Undo - a big PIA, but I
> > think I should stop that - it wastes my time. So what if the two
> > versions are identical?
... as a reply to the end-to-end refactoring that include the PageDef
meta-data: this feature is on the radar and we are getting closer with
every release. For the next release, the one after JDev 11g R1
PatchSet 1, I got some suggested ER accepted in this area.
Frank
On Sep 21, 1:01 pm, susan duncan <susan.dun...@oracle.com> wrote:
> In the next release of JDeveloper you will see great improvements to
> preemptive file check out. This is something that our Fusion developers
> also identified and has been worked on.
> In general, and this goes for all aspects of JDeveloper and all users,
> if you have problems such as this I would urge you to log support calls
> so we can ensure that we catch your use cases on bugs. I realise that 1.
> you may not have support, 2. it takes time but it is effective.
> rgds
> Susan
> On 20/09/2009 23:55, John Flack wrote:
> > Nathalie -
> > Your comment about re-factoring just hit home. I've got an
> > experimental project going right now, and the experiment wasn't going
> > well so I am about to do a major re-factoring and try a very different
> > direction. To some extent, the IDE is still helping me. For
> > instance, I just deleted a class, and JDeveloper offered to "Delete
> > Safely". It then showed me all my files where that class was being
> > used. On the other hand, I still had to remove the references to the
> > defunct class manually. I also wanted to delete some attributes from
> > an Entity Object, and JDeveloper wouldn't let me until I had first
> > deleted the corresponding attributes from the View Object.
> > I'm not sure how much more the IDE can do to help, though - I'd still
> > want to control what gets deleted and what re-written.
> > Source control is also VERY important when you have so many files.
> > I'm using ClearCase, and JDeveloper tends to preemptively check out
> > many more files than I actually change, especially when I change an
> > Application Module. I either have to Undo checkout of any file I
> > didn't change, or let ClearCase check in copies that are identical to
> > the previous version. I've tended to do the Undo - a big PIA, but I
> > think I should stop that - it wastes my time. So what if the two
> > versions are identical?
Thanks a lot for the reply.
I would like to give an overview of the different refactoring-issues
that are adressed in the releases of Jdeveloper, so the community's
aware of the efforts being performed.
Is it possible to have some sort of a report showing which issues are
addressed in Jdev 10.1.3.x until 11g and later, so we can share this
in the ADF EMG and put this on the wiki as well? That would be great.
Kind regards,
Nathalie
On Sep 24, 7:42 am, fnimphiu <frank.nimph...@googlemail.com> wrote:
> ... as a reply to the end-to-end refactoring that include the PageDef
> meta-data: this feature is on the radar and we are getting closer with
> every release. For the next release, the one after JDev 11g R1
> PatchSet 1, I got some suggested ER accepted in this area.
> Frank
> On Sep 21, 1:01 pm, susan duncan <susan.dun...@oracle.com> wrote:
> > Hi John,
> > In the next release of JDeveloper you will see great improvements to
> > preemptive file check out. This is something that our Fusion developers
> > also identified and has been worked on.
> > In general, and this goes for all aspects of JDeveloper and all users,
> > if you have problems such as this I would urge you to log support calls
> > so we can ensure that we catch your use cases on bugs. I realise that 1.
> > you may not have support, 2. it takes time but it is effective.
> > rgds
> > Susan
> > On 20/09/2009 23:55, John Flack wrote:
> > > Nathalie -
> > > Your comment about re-factoring just hit home. I've got an
> > > experimental project going right now, and the experiment wasn't going
> > > well so I am about to do a major re-factoring and try a very different
> > > direction. To some extent, the IDE is still helping me. For
> > > instance, I just deleted a class, and JDeveloper offered to "Delete
> > > Safely". It then showed me all my files where that class was being
> > > used. On the other hand, I still had to remove the references to the
> > > defunct class manually. I also wanted to delete some attributes from
> > > an Entity Object, and JDeveloper wouldn't let me until I had first
> > > deleted the corresponding attributes from the View Object.
> > > I'm not sure how much more the IDE can do to help, though - I'd still
> > > want to control what gets deleted and what re-written.
> > > Source control is also VERY important when you have so many files.
> > > I'm using ClearCase, and JDeveloper tends to preemptively check out
> > > many more files than I actually change, especially when I change an
> > > Application Module. I either have to Undo checkout of any file I
> > > didn't change, or let ClearCase check in copies that are identical to
> > > the previous version. I've tended to do the Undo - a big PIA, but I
> > > think I should stop that - it wastes my time. So what if the two
> > > versions are identical?- Hide quoted text -
This isn't really a solution to the problem, but it may be something
to keep in mind:
*Any* Java EE application has a lot of files. Fusion apps have a lot
more XML files than most, but they have a lot fewer Java classes than
most. In a lot of cases, it's almost a 1-1 replacement. E.g.:
-Most entity object definitions don't require any custom Java classes
nowadays. So, e.g., you have the EO XML instead of a Hibernate-mapped
class.
-Most pages/fragments don't need backing beans to access model
information. So you have a pageDef file instead of a backing bean
class.
-Similarly, you have declarative components instead of subclasses of
Faces component classes.
And so on.
I do agree with Nathalie--refactoring the XML files isn't as smooth a
process as it should be, and I look forward to the improvements Frank
mentions.
I would love to know the specific problems people are finding with refactoring so I can make sure we have them all listed as things we need to work on.
John, about deleting components. As I think you've guessed the current behaviour is a deliberate design decision: we can't guess what you want to do with each outstanding reference so we list them all in the log window and let you double-click on each reference to open the file and decide how you want to handle it.
John Flack wrote:
> Nathalie -
> Your comment about re-factoring just hit home. I've got an
> experimental project going right now, and the experiment wasn't going
> well so I am about to do a major re-factoring and try a very different
> direction. To some extent, the IDE is still helping me. For
> instance, I just deleted a class, and JDeveloper offered to "Delete
> Safely". It then showed me all my files where that class was being
> used. On the other hand, I still had to remove the references to the
> defunct class manually. I also wanted to delete some attributes from
> an Entity Object, and JDeveloper wouldn't let me until I had first
> deleted the corresponding attributes from the View Object.
> I'm not sure how much more the IDE can do to help, though - I'd still
> want to control what gets deleted and what re-written.
> Source control is also VERY important when you have so many files.
> I'm using ClearCase, and JDeveloper tends to preemptively check out
> many more files than I actually change, especially when I change an
> Application Module. I either have to Undo checkout of any file I
> didn't change, or let ClearCase check in copies that are identical to
> the previous version. I've tended to do the Undo - a big PIA, but I
> think I should stop that - it wastes my time. So what if the two
> versions are identical?
I'm sure the members of the forum are happy to help, but before they
commence can you outline what known bugs exist for refactoring in JDev
and when they're scheduled for a fix please? I'd hate people to go
and put a lot of effort in to discover Oracle already has lthe bug
logged in detail, and worse, to dishearten any effort, has no fix
scheduled.
|
