• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Dynamic screen and table generation

 
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
We have an j2ee based web application where currently the screens are static with heavy usage of JavaScript .
we have a requirement where we would need to built the screens dynamically. Each screen denotes one table . Could anybody let me know any web based approach where we could create the screens dynamically. There are lots of calculation occurring in each fields using JavaScript .
we need that all this need to be somehow generated dynamically by the admin user of the application who will have the capability to iinput all the details (formulas, calulations) etc by himself. Also how
could we achive the db design for this approach.

What type of architecture is best suitable for such a requirement where the screen itself can be added by the admin user of the aplication . The biggest challenge i think to how do we create such screens dynamically using some meta data approach and how do we represent such data

Any help on this is highly appreciated
 
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
My advice is, don't do that. You should use static screens, it's much easier to implement and more importantly ... to change.

From my expirence, it's appealing an idea at first, but it's very difficult to make it flexible, and the code will be much more complicated than using static screens.
 
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Each screen denotes one table is not a good idea, but it is a time-saving idea.

The db design solution depends on much more investigation from business level.

And important part is DB designing is the first step to do this task.
 
Hong Anderson
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

yooon chin wrote:Each screen denotes one table is not a good idea, but it is a time-saving idea.


In most applications it's not a good idea, but in specific area of applications it's good. For example, DBMS front-end applications can generate screen to edit data dynamically based on the table schema. It's all right because the users of the application are technical users.

But for an application that its users don't have technical perspective doing this might save time at first, but it'll consume more time later in struggling to make the UI richer or make some screens differ from other screens. UI generator is best if all screens look the same, but if each screen can be different it would be difficult to make the UI generator flexible enough and the code will be much more complicated that it's needed to be.
reply
    Bookmark Topic Watch Topic
  • New Topic