14 replies to this topic

[Jim]

Hello,

This is a general query about application frameworks and I'm hoping to draw upon the knowledge of some of the forum members to give me a steer. I read with interest the recent posts and positive feedback regarding the OpenClient release as part of P4 v6 - it appears to effectively address most of the weak areas in terms of presentation layer, client-side installs etc. that ProIV has historically had aimed at it.

We all know that as a dev environment ProIV is very quick and scales well, however I have a requirement to develop a discreet module with no legacy system baggage and wanted to see if any members could share opinions/experience. I apologise if this seems off topic for a P4 forum, however I am aware from previous posts that many members here are multi-disciplined wrt I.T. and any information gained from first-hand experience is always valuable.

If starting a project where there was an even mix of ProIV/Java/.NET resources available, would P4 v6, ASP .NET or Java (Struts, Hibernate/Spring?) be your preferred starting point, or even other approaches that I haven't touched upon above, and why? The main requirements are:

- a rapid development environment, with a good separation of model, view (hopefully template driven/standardised), controller roles

- interaction with a variety of JDBC 2.0 compliant databases

- browser based UI, with no plugins beyond the usual suspects (perhaps javascript and java plugin, or whatever microsoft bundle with their recent OSes in terms of .NET framwork etc. - client base is almost exclusively Windows flavours)

- good support for web services, xml input/output/parsing

- open or closed source frameworks considered - the main consideration is development time and reliability/scalability

Thanks for any input you can provide. Please no flame-wars!

[Chris Mackenzie]

Hello,

This is a general query about application frameworks and I'm hoping to draw upon the knowledge of some of the forum members to give me a steer. I read with interest the recent posts and positive feedback regarding the OpenClient release as part of P4 v6 - it appears to effectively address most of the weak areas in terms of presentation layer, client-side installs etc. that ProIV has historically had aimed at it.

We all know that as a dev environment ProIV is very quick and scales well, however I have a requirement to develop a discreet module with no legacy system baggage and wanted to see if any members could share opinions/experience. I apologise if this seems off topic for a P4 forum, however I am aware from previous posts that many members here are multi-disciplined wrt I.T. and any information gained from first-hand experience is always valuable.

If starting a project where there was an even mix of ProIV/Java/.NET resources available, would P4 v6, ASP .NET or Java (Struts, Hibernate/Spring?) be your preferred starting point, or even other approaches that I haven't touched upon above, and why? The main requirements are:

- a rapid development environment, with a good separation of model, view (hopefully template driven/standardised), controller roles

- interaction with a variety of JDBC 2.0 compliant databases

- browser based UI, with no plugins beyond the usual suspects (perhaps javascript and java plugin, or whatever microsoft bundle with their recent OSes in terms of .NET framwork etc. - client base is almost exclusively Windows flavours)

- good support for web services, xml input/output/parsing

- open or closed source frameworks considered - the main consideration is development time and reliability/scalability

Thanks for any input you can provide. Please no flame-wars!

Use pro-iv v6.2 would be my response. Development time is much lower than Java, code is easier to maintain long term. Works across any type of server which is where .net which I have no experience of would fall down. The ease of interaction between p4 and Java libraries with 6.2, combined with the p4 web services framework, should give you everything you need.
jm2c

[Neil Hunter]

Just remember that OpenClient is a chargeable extra as a per user licence

[Jim]

Chris, Neil,

Thanks for the replies. Both useful information - good to know the p4 interaction is reliable, and also the per seat license for the open client was news. If anyone else wants to give their 2c please do - all opinions/information gratefully received.

Regards,
Jim.

[Richard Bassett]

> Just remember that OpenClient is a chargeable extra as a per user licence

Oh no.. are you serious?
Anyone know roughly how much extra?

[Richard Bassett]

Jim,

I don't have that much input re. your original question but if you're inclined to use Java one thing to look at is Google Web Toolkit (GWT) which allows you to write the UI in Java and compiles it to Javascript etc. portable to all web browsers.

http://en.wikipedia....gle_Web_Toolkit

[Neil Hunter]

> Just remember that OpenClient is a chargeable extra as a per user licence

Oh no.. are you serious?
Anyone know roughly how much extra?

Dead serious....

At our recent user conference in South Africa, figures of 75 pounds per seat were being thrown around. I gather that is before VAR discounting. You could hear the whole room sigh

[Glenn Meyers]

They HAVE gone round the bend.

[Jim]

Jim,

I don't have that much input re. your original question but if you're inclined to use Java one thing to look at is Google Web Toolkit (GWT) which allows you to write the UI in Java and compiles it to Javascript etc. portable to all web browsers.

http://en.wikipedia....gle_Web_Toolkit

Thanks for the input Richard. I had been looking at JQuery to get some fairly smooth client-side UI behaviour but already came across issues that required debug(h)ging Javascript. GWT was mentioned as an alternative due to the relative ease of debugging Java.

That per-seat license issue others have mentioned would probably not be terribly relevant for the non-public module I am scoping, but sounds quite restrictive for public facing applications.

Regards,
Jim.

[ArmChair]

Jim,

I don't have that much input re. your original question but if you're inclined to use Java one thing to look at is Google Web Toolkit (GWT) which allows you to write the UI in Java and compiles it to Javascript etc. portable to all web browsers.

http://en.wikipedia....gle_Web_Toolkit

Thanks for the input Richard. I had been looking at JQuery to get some fairly smooth client-side UI behaviour but already came across issues that required debug(h)ging Javascript. GWT was mentioned as an alternative due to the relative ease of debugging Java.

That per-seat license issue others have mentioned would probably not be terribly relevant for the non-public module I am scoping, but sounds quite restrictive for public facing applications.

Regards,
Jim.

Jim,

Debugging Javascript is not very difficult these days. Firefox has a very neat plugin, Firebug, which lets one set breakpoints, watch variables and objects, step through code et al. Safari has similar features. Even IE8 has these developer tools built in.

[Matthews Estrice]

Hi Jim,

I am working on PROIV v6.2.
I would develope Java (EJB,Struts,Hibernate/Springs,Model-View-Controller and annotation,Ajax,JSON,JavaFX,JSP,servlets,JavaScripts,WSDL,SOAP,SAX,POI,iText,mob
lity,Multi-threading,RMI,FOP ,(JAAS)Java Authentication and Authorization Service, etc),CSS.I installed both GlassFish and Apache Tomcat and that seems to be working together well with Jetty-Tomcat.
I then deploy all the above on a SINGLE .war file or export the WEB-INTF project to a servlet containor, as a financial application and deploy all
under SSO directory on PROIV.My main application is sitting on PROIV.

I can move my source to and from NetBeans and Eclipse IDE.

I interfaces with SAP using Netweaver.

I can then do IO of CSV,XML,EXCELL,PDF,emails,ODBC,JDBC looking at various database also working C-ISAM and PRO-ISAM file using PROIV Tasks.

I can be on Linux/Unix or windows ENV (but not VISTA ).

That is what I would call it "The platform that enables you to consolidate heterogeneous systems, applications, and data to simplify the IT environment and reduce operational costs, freeing resources to focus on strategic, innovative solutions".

PROIV interfaces with the J2EE environment using SSO (especially JAVA DAOs) SPRING FRAMEWORK using .jar or .war.

I manage to use JFreeCahrt and Bar graphs under PROIV's SSO.

I would start of from PROIV and end with J2EE.
Jim, it depends on how big your project is and how skillfull are you or your team and what environment you intending to run your frameworks.

I hope this contributes to your question.If not, I apologise for wasting your time.This is based on what I am currently doing and it works.

Cheers,
Matthews

[Jim]

Armchair, Matthews,

Thanks for your replies. Matthews thanks for the level of detail - it is very helpful to get a picture of the plumbing of a flexible framework such as the one you have outlined. We are currently dealing with a large legacy ProIV app and this newer application may at some point require and interface into it, so the SSOs using Spring could turn out to be relevant.

Regards,
Jim.

[Matthews Estrice]

You are welcome Jim.

[Matthews Estrice]

This is a good example,

If your class is packaged on the .war with the class below, under the SSO,you can call this class in PROIV and re-use its DAO methods in PROIV logic.

import javax.sql.DataSource;import org.springframework.jdbc.core.JdbcTemplate;public class ExecuteDBStatement { private JdbcTemplate jdbcTemplate; public void setDataSource(DataSource dataSource) { this.jdbcTemplate = new JdbcTemplate(dataSource); } public void doExecute() { this.jdbcTemplate.execute("create table mytable (id integer, name varchar(100))"); }}

[Jim]

This is a good example,

If your class is packaged on the .war with the class below, under the SSO,you can call this class in PROIV and re-use its DAO methods in PROIV logic.

import javax.sql.DataSource;import org.springframework.jdbc.core.JdbcTemplate;public class ExecuteDBStatement { private JdbcTemplate jdbcTemplate; public void setDataSource(DataSource dataSource) { this.jdbcTemplate = new JdbcTemplate(dataSource); } public void doExecute() { this.jdbcTemplate.execute("create table mytable (id integer, name varchar(100))"); }}

Thanks Matthews will have to look further into this. Haven't been on the board for a few weeks.

Regards,
Jim.