Abdullah Shaikh wrote:
This way the FTL pages will be free of any logic and will just render the
data provided through context from Groovy.
If using this technique,
1) Every FTL page will require a Groovy file for data preparation logic
2) Any changes can be does easily as Groovy won't require server restart
3) Changes in the UI can be done easily as we just need to paste the new UI
code and get appropriate data from context and display it where ever you
require.
We can decide on a model for passing data to FTL pages, for example
Groovy :
data.put("userdetails", userdetails);
data.put("paymentsinfo" paymentinfo);
data.put"shoppingcart", shoppingcart);
context.put("data", data);
FTL :
<table data.get("userdetails")</table>
<table>data.get("paymentinfo", paymentinfo)</table>
<table>data.get("shoppingcart" shoppintcart);
I think the danger here is that you are going to move HTML from the view
up into the logic. At that point, editing the Groovy file is totally out
of the designer's reach. If those data elements can be made extremely
generic and provide good CSS hooks then maybe it is a solution and helps
make the FTL less fragile. Handled incorrectly it will just require
design changes to be implemented by the programmer in the Groovy file.
