Re: [ADF EMG] Why Oracle likes PageDefs so much?

[Florin Marcus]

Hi Manoj,

My two cents:

Page bindings concept is unique among Java Enterprise technologies and from my perspective it was introduced for design-time reasons,  to easier support JDeveloper drag-and-drop development.  As from runtime perspective, I cannot think of any reason ADF authors would prefer it instead of managed beans/ annotations. At the end of the day, each page binding becomes an object at runtime.

Thanks,

Florin Marcus

Red Samurai Consulting

On 22 Dec 2012, at 22:51, Manoj kottam <manoj....@gmail.com> wrote:

Hi All,

I have been using ADF since the 10g days. Only with the 11gR2 (thanks to Facelets) release, I can recommend going for ADF to clients without a guilty conscience. I have some bad expereinces with pageDefs and would like to see a better alternatives to pageDefs, more specifically, is there a better way to manage the bindings other than a pageDef xml file? 

I like annotations and dependency injection better. Would be nice if I can inject the bindings through annotations in backing bean (or on jsf page.. not sure if it can be done).

In my experience I see these as the cons of pageDefs:

1. Another xml document to maintain in the source code. PageDefs being auto generated and auto updated by JDeveloper, the subversion (any version control) conflict resolution becomes a nightmare.

2. ADF Security forces you to have a PageDef to properly secure the page. So unnecessary pagedefs lying around in the code.

3. When a jsf/jspx page is deleted, the pageDef references are not easily deleted. Ends up having a page name as page.jspx and the pagedef name as page1PageDef.xml

4. If a component is commented on a jspx page, the corresponding bindings in the pageDef are not automatically commented and hence takes up unnecessary init/memory in JVM at runtime.

5. Too much of xml.

6. Editing a pageDef can easily become a pain if a viewobject has a new column added.

I haven't seen the concept of PageDefs in other JSF implementations. And yeah they don't have the awesome datacontrols that ADF has ( :) I don't have much affection for data controls either. I still don't know why they keep calling a request twice or (thrice in some cases) ).

Please share your experiences while managing the pageDefs.

Thanks

Manoj

--
You received this message because you are subscribed to the ADF Enterprise Methodology Group (http://groups.google.com/group/adf-methodology). To unsubscribe send email to adf-methodolo...@googlegroups.com
 
All content to the ADF EMG lies under the Creative Commons Attribution 3.0 Unported License (http://creativecommons.org/licenses/by/3.0/). Any content sourced must be attributed back to the ADF EMG with a link to the Google Group (http://groups.google.com/group/adf-methodology).

[Edwin Biemond]

Hi,

Indeed, pagedef can be a little bit annoying , but for security and the variables iterator they should remove it from the pagedef.
plus iterators which are not called or used should not be refreshed ( lazy loading ) even when it has always refresh.

I also think they went too far with it , example is contextual events ( now you need to make dummy dc and add these to the pagedef , just to fire or listen to an custom event )
also some adf rich components has in the early days much more attributes like lov components and they move the complexity in the adf bc or adf binding layer. it works great in adf bc but from pojo it has become really hard,

also when you skip adf binding and have jpa, ejb and later cdi you don't have detached entities which helps you to update it directly ( no merge operation) and have commit and rollback.

but for fusion apps and most of our developers it works great and they dont look or care about these files. maybe the solution can be to have adf annotations and add these to managed beans or jpa ( on fields , classes or methods ) which influence adf rich faces components.

thanks Edwin.

[Steve Muench]

Would the technique in example #164 on my blog avoid the need for creating a "dummy" DC here?

https://blogs.oracle.com/smuenchadf/resource/examples#164

[John Flack]

1. Another xml document to maintain in the source code. PageDefs being auto generated and auto updated by JDeveloper, the subversion (any version control) conflict resolution becomes a nightmare.

I'm not sure why XML documents are any worse than Java source code.  Java source is text, so is XML - source control tools like text.  And for my team, whose Java experience is limited, XML may be better.  Auto-generation is always a double-edged sword, but I'll lean in its favor because of the speed of development it gives.

 

3. When a jsf/jspx page is deleted, the pageDef references are not easily deleted. Ends up having a page name as page.jspx and the pagedef name as page1PageDef.xml

True - you have to know where all the pieces are that have to be deleted.  But we don't delete pages very often, and once you know the procedure, I don't think it is very hard.  I've never wound up with the situation you describe.

 

4. If a component is commented on a jspx page, the corresponding bindings in the pageDef are not automatically commented and hence takes up unnecessary init/memory in JVM at runtime.

With source control, I rarely comment out code, except temporarily during unit tests.  While, admittedly, unused bindings have a cost, I can't see that it would be significant.  If I decide not to use a control anymore, I delete it, and if I'm working in design mode, the pageDef is updated.

 

5. Too much of xml.

Why is this a problem?

 

6. Editing a pageDef can easily become a pain if a viewobject has a new column added.

I think that is a cost of MVC, not of pageDefs - adding things to the model doesn't affect the view unless you want it to.  But if you drag and drop the new field on a page from the data control, the pageDef gets changed too.

[Edwin Biemond]

Hi Steve,

Thanks for the link,  but I need to have Events ( to decouple BTF) and pass on complex object types.  

Now with ADF Essentials and Java EE 6 I will try CDI Events together with ADF on GlassFish

this way I can interact in a loosely coupled way by firing and observing events

like described by your collegae Arun Gupta

https://blogs.oracle.com/arungupta/entry/totd_145_cdi_events_a

http://netbeans.org/kb/docs/javaee/cdi-events.html

http://docs.oracle.com/javaee/6/tutorial/doc/gkhic.html

thanks Edwin

[Edwin Biemond]

Hi John,

I really like the Jdeveloper 11gR2 minimal approach ( using defaults )  especially when working with pojos and DataControls. Only generate xml when it is necessary. ( off course nowadays this could also be combined by ADF or other annotations )

When working with ADF BC then xml is ok ( it starts with xml and you can generate java classes ) and has a lot of benefits to do nice things for FMW ( like develop ADF BC in your browser or in combination with MDS ) but I think with ADF BC always generate classes when you want to do typesafe developing. And an another good thing is that ADF BC has java data types as default instead of all the Oracle Data Types. 

With JPA you have pojos with annotations and you can use an object relational mapping xml or do both , I think most java developer use annotations ( all config in one place, never out of sync, compiles, plus use plugins like sonar ) 

but for soa suite they use an orm xml with the db adapter, this is more handy for the soa developer (already have many xmls), jdeveloper plugins and for svn ( in 10g you had classes and xml , never knew what files are used )  

Conclusion keep everything in one file, java or xml , both can be a little bit harder to develop. 

but in my case, forced by most architects I have to work on web services, use Java EE ( bean validation,CDI ) or use JPA ( decouple , typesafe )  In that case all the extra generated xml is annoying and not necessary. 

So it depends on the team and what you are developing.  I know with ADF you can start faster & develop faster, but we earn this back in the complete application lifecycle, ( more lightweight,  java developers are easy to find and are cheaper , java code qualitity is great, unit testing plus code coverage, hudson and sonar, maven,  plus easy to upgrade ) .

thanks

[Shay Shmeltzer]

Manoj,

You should look into the ADF debugging which actually allows you to set break points on the XML files, and get an insight into the framework's variables, state etc.
Here is a quick overview: https://blogs.oracle.com/shay/entry/introduction_to_the_adf_debugger

In fact, if I'm not mistaken in CDI and other annotations, you can't set a breakpoint on a @ annotations - which makes it harder to debug compared to the XML approach of ADF.

One aspect that wasn't mentioned in this discussion about XML vs Annotations is that with the XML approach we are able to do runtime and design time customization with MDS. by overlaying XML definitions we can do customization at each layer of the MVC, and also customization across other solutions such as WebCenter and SOA processes.
If you are not familiar with MDS - here is a quick overview:
http://download.oracle.com/otn_hosted_doc/jdeveloper/111demos/mds/mds.html

Further arguments in this XML vs Annotations debate are in this article:
http://duncanmills.sys-con.com/node/735111?page=0,0


Shay

On 12/27/12 9:20 AM, Manoj kottam wrote:

Hi John,

Once simple reason for not preferring xmls is debugging. Any developer would agree, it is easier to debug a java configuration class than an xml configuration. Even Spring now supports fully Java class annotated configurations.

Thanks

Manoj 

--

[Florin Marcus]

Every single J2EE developer I've met, when starting with ADF has this question in mind : why so much XML?

The truth is that popular frameworks like Hibernate or Spring offer both options: annotations and XML, leaving this decision to developers. (And yes, those open source technologies are perfectly capable of handling complex, large applications just as much ADF does, though ADF is more productive once you've learn it)

Compile-time validations was always an argument used in favour of annotations, but JDeveloper does a great job on compiling/validating the XML data.

Tooling support and MDS are strong arguments in favour of ADF XML based architecture, hard to argue with that. 

But I think what Manoj was questioning  is the use of backing beans with annotations as a replacement of page bindings, not necessary about having the whole ADF stack XML-less. In this particular area, I must confess I wouldn't mind an annotation-based alternative to page bindings.

Thanks,

Florin Marcus

Red Samurai Consulting

Sent from my iPhone

On 27 Dec 2012, at 20:35, Manoj kottam <manoj....@gmail.com> wrote:

Thanks for the links Shay.

Wow... the post from Duncan Mills is posted way back in 2008. Can't argue with that :)

The whole MDS is a different argument. I love it and hate it (It can potentially make your source code messy ).

Thanks

Manoj

[Chad Thompson]

On 27 Dec 2012, at 23:07, Florin Marcus wrote:


> Tooling support and MDS are strong arguments in favour of ADF XML
> based architecture, hard to argue with that.
>
> But I think what Manoj was questioning is the use of backing beans
> with annotations as a replacement of page bindings, not necessary
> about having the whole ADF stack XML-less. In this particular area, I
> must confess I wouldn't mind an annotation-based alternative to page
> bindings.

Coming into this thread late - I have to agree with this; the nice thing
that annotations have replaced in JavaEE is the amount of configuration
and boilerplate code that needs to be generated. The XML Page
Definitions, etc. usually have not been a problem until we get to issues
of conflict resolution - merging XML documents often requires some
knowledge about the schema and/or the underlying logic behind page
definitions.

Annotations in JavaEE eased that burden somewhat (annotated class files
don't require specific schemas or syntaxes) - reducing the XML
dependencies in ADF would ease team development.

(I can say this after having to merge together two 'struts-config.xml'
files in an old application. Merging two 2,000 line XML files together
= "uff da", in the language of my fore bearers.)

- Chad

[Andreas Koop]

Hi everybody,

from customers (developers) feedbacks there is not just the discussion about Annotation vs. XML based pros and cons but in the end I often hear the following issues:

- Standards. Although the ADF framework belongs to the Java EE Web Framework category with the ability to put together JSF / JPA / EJB3 the Binding Layer - and so PageDefs - does not belong to any Java EE Spec. The JSR-227 was not successful and there is currently no hint it ever will be. Instead CDI has evolved as the "Binding Glue". So CTOs and architects are scared of that Oracle proprietary PageDef Stuff. Further: Compared to ADF Taskflows the PageDefs are definetly no driver for the Java EE future.

- Bad API Design. Well. I know we are talking about PageDefs here, but in practice you often need to work with the PageDefs Objects through the Binding-API which is really bad designed. There is a lot of Classes to deal with, mixed up with ADF BC (jbo.*) stuff even if you are using POJO or WS Model.

- Complexity. In most other frameworks the trend is to make things simpler. With PageDefs there comes just another layer of complexity. Of course there are many advantages but most developers do not want those to use, e.g. validations: Instead they want to use Bean-Validation. Caching in the Binding-Layer and so on.

- Type-safety. There is no compile time safety.

- Refactoring. Always a problem with pageDefs. Need to know how things belong together. Newbies are most time lost!

Well, actually I think, with the great IDE integration into JDeveloper there is no big deal with the XML + Developers easily get the connection from data usage to its data source in the bindings view. Refactoring is getting better and better.

I am curious for 2013 how the PageDefs and/or CDI approaches will evolve in ADF.

Regards,

Andreas Koop

www.enpit-consulting.com

Am Donnerstag, 27. Dezember 2012 19:35:20 UTC+1 schrieb Manoj kottam:

Thanks for the links Shay.

Wow... the post from Duncan Mills is posted way back in 2008. Can't argue with that :)

The whole MDS is a different argument. I love it and hate it (It can potentially make your source code messy ).

Thanks

Manoj

On Thursday, December 27, 2012 11:40:35 AM UTC-6, Shay Shmeltzer wrote:

[Renan Monteiro de Castro]

Hello John Flack!

About the following:

5. Too much of xml.

Take a look here:

http://docs.oracle.com/cd/E15586_01/web.1111/b31974/appendixa.htm

Do you really think, I mean, "really" that having more than ten XML files to control application configuration worth it?

I mean, all modern frameworks are trying to reduce that number, for newer web frameworks like Rails or Django you end up with just one

configuration file... And that's only pure text.

The advantages is that most of the time you find what you want far more easily than having to search inside more than ten XML configuration files (not to mention pageDefinition files, the topic main discussion).

Right now ADF is a pain to newbie programmers, even those Java medium-level programmers suffer with it, the learning curve is big and you have to read ALOT, even if you read the docs, most of the time you'll end up finding the answer in a "how-to" over the web inside any blog post (those ADF evangelists with more than 5+ years of framework knowledge).

It is really common to have projects around there scheduled for six months, do you think someone can learn and deliver some good-well-made-software having to learn ADF and produce within six months? In my opinion, its impossible... Even if you can deliver some software within that period with Oracle ADF, you end up doing some weird implementations because of the complex ADF Architeture and the just-in-time necessity to solve problems. I mean, some ADF implementation choices you made in your project can cause a lot of trouble after some months of production release or even when the user is going to test it.

For me, the XML frameworks is not going too much forward, it is not on Java EE plans and neither of any other framework around the web.

Those "more than ten config XML files" makes me wonder everyday if it does worth the advantages (if any). 

Did you take a good look at "adf-settings.xml"? A configuration file that usually wont go trough more than 50 lines of writing...

--

You received this message because you are subscribed to the ADF Enterprise Methodology Group (http://groups.google.com/group/adf-methodology). To unsubscribe send email to adf-methodolo...@googlegroups.com
 
All content to the ADF EMG lies under the Creative Commons Attribution 3.0 Unported License (http://creativecommons.org/licenses/by/3.0/). Any content sourced must be attributed back to the ADF EMG with a link to the Google Group (http://groups.google.com/group/adf-methodology).

--

Renan Monteiro de Castro - Linkedin

[Stephen Johnson]

It sounds like the core of this argument isn't so much XML vs. not-XML, but rather the number of files that have to be maintained.  For both the pagedefs and the config files it's more a matter of having too many files to maintain (and to learn about) than it is a matter of what those files are written in.

Stephen Johnson

Sent from I, Pad

[Jang Vijay Singh]

Hi,

My two paise on the too many xml files argument:

Not all the XML files in an ADF application are "application configuration". 

Most of them (including pageDef in ADFui and then ADFbc component xml's) are component definitions.

 Just so happens that instead of another notation (java source code? Text?), most of the component definition (and its customizations) also resides in XML - this makes them more a) design tool friendly b) wizard friendly c) customization friendly d) probably also easier to develop for the actual framework developers who develop and maintain ADF. 

The design time and runtime versions of these component definitions can be very different after merging of the customization layers and XML is handy in facilitating this 'merge' with ease (to me it does). 

It also facilitates easy storing of outputs of graphical tools - virtually all the ADF component editors. 

Regards,

JV

[John Flack]

I agree with Stephan Johnson that the problem may be too many configuration files, not that those files are XML.  When I started learning Java, I felt that Java had too many files – classes extending classes that extend other classes, and implementing interfaces, and where do you find the source for the method that you want to call?  If this stuff isn’t well documented, it can be a nightmare, especially for an old 3GL programmer like me, where entire application systems might be in a few source code files – big monolithic programs.

On the other hand, keep in mind that the principal audience for JDeveloper and ADF was and is the developers who were used to 4GL tools like Oracle Forms, not Java.  For them, while the underlying structure may be a bunch of XML files, the key factor is that they don’t have to write XML and they don’t have to write Java.  They drag and drop, fill in some property forms and let the IDE do the rest.  For most of the XML files that I modify on a regular basis, JDeveloper offers nice fill in the blank forms.

Two of the developers on my team were Java programmers who had used other frameworks.  We have two application systems they wrote and (since I was not the team leader at the time) they were permitted to do it the way they knew best.  They used JPA, generated with Hibernate, for the Model.  While they did use JDeveloper and ADF Faces for the View, they did not use the ADF binding framework in the Controller.  Instead they wrote Managed Beans for their bindings.  So they have no pageDef files.  The applications work, but it took them much longer to write the applications than my applications using the entire ADF framework.  Longer than one of my team members who came from a ASP.Net environment.