<FONT face="Default Sans Serif,Verdana,Arial,Helvetica,sans-serif" size=2>Martin<br><br>Further to my previous email: There is a spreadsheet loader that we can use to turn a (relatively ?) simple if-then-else data layout into a multi-page user interface. We also have a prototype of a UI builder for a calculation engine, but it is still too early for prime-time. The UI generation can make use of normal drools files to augment the logic. <br><br>By the sounds of it, apart from possibly the admin system, you are looking at standard drools logic which is probably where I would recommend that you start. Taking this approach means that you can delay the UI technology choice until you have more information and/or a better feel for the direction(s) you want to take?<br><br>Feel free to correct my impression of what you are after :-)<br><br>Regards<br><br>Derek<br><div><br></div><div><br>--<br>Derek Rendall<br>Architect<br>Solnet Solutions Limited<br>Level 7, Brookfields House<br>19 Victoria Street, Auckland 1010, New Zealand<br>PO Box 6619, Auckland 1141, New Zealand<br>DDI +64 9 977 5852, Mobile +64 27 4478471<br>Main +64 9 977 5800, Fax +64 9 977 5801<br><br><a href="http://www.solnetsolutions.co.nz">www.solnetsolutions.co.nz</a> <br>A Solnet Group Company <br><div><br></div><font color="#990099">-----tohu-users-bounces@lists.jboss.org wrote: -----<br><br></font><blockquote style="padding-right: 0px; padding-left: 5px; margin-left: 5px; border-left: 2px solid #000000; margin-right: 0px;">To: tohu-users@lists.jboss.org<br>From: Martin Meyers &lt;Martin.Meyers@web.de&gt;<br>Sent by: tohu-users-bounces@lists.jboss.org<br>Date: 08/12/2010 08:23PM<br>Subject: [tohu-users] Help needed -- Is Tohu appropriate for my app        scenario? (2nd try)<br><br>


  


Dear Tohu community members:<br><br>
Really no suggestions here?!?<br><br>
I'd need and very much appreciate any clarifications of the mentioned
issues.<br><br>
Again, thank you very much<br>
&nbsp; Martin<br><br><br>
=== Original Email ===========<br><br>
Dear Tohu community members:<br><br>
Doing a research on *questionaires with (rule-based) dynamic behaviors*
I was led to Tohu. <br>
Now, after having viewed the introductory videos and overflown the core
aspects in the docu, I'm still wondering if Tohu is right for solving
project requirement. So, I'd need some help &amp; suggestions from more
experienced Tohu users/developpers.<br><br>
The project is a JEE 5/6 app using JPA(2) at the backend and JSF(2) or
GWT2 at the frontend, basically presenting *Interactive/Smart/...
Purchase Order Forms* which involve declarative/dynamic client-side
prestentation logic and declarative/dynamic server-side processing
logic, both defined a priori by "admin users".<br><br>
To be more precise, imagine we've the following minimalistic scenario:<br>
<i>Customers of diff. types (e.g. {BRONZE, SILVER, GOLD}) are presented
a customer-type specific catalog composed of atomic products and
product bundles for ordering purposes. A product has diverse prices
depending on pricing parameters like customerType, quantity, ordering
period (timespan valid for a price), stock levels, etc. A product
bundle is comprised of N products and has the same diverse prices
depending on the same pricing parameters, but probably granting some
bundle discounts when summing them up. <br>
</i><br>
So, I'd derive a domain model like this (please correct me if there's a
better way):<br><br>
<i>&nbsp; 'Customer' (id, name, ..., orders, customerType), <br>
&nbsp; 'CustomerType' being admin-specified categorization like { BRONZE,
SILVER, GOLD }<br><br>
&nbsp; 'Order' (id, date, customer, lineItems, ..., total) and<br>
&nbsp; 'LineItem' (id, productRef, quantity, lineTotal) <br><br>
&nbsp; 'Product' (id, name, descr, category, [stdPrice], pricingRef) and<br>
&nbsp; 'ProductBundle' (id, name, descr, category, products, [stdPrice],
pricingRef)<br><br>
&nbsp; 'Pricing' (id, productRef, pricingParams, price) <br>
&nbsp; 'PricingParam' &lt;= 'customerType' and/or 'orderingPeriod' and/or <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 'stockLevel' (and/or 'orderedWith'(???)).<br>
&nbsp; 'PriceCatalog' (id, listOfPricings).<br><br>
&nbsp; [There also could be 'Price', 'Currency', 'Money', 'Discount', ... if
needed]. 
</i><br><br>
Not quite sure how to model the bundle-pricing strategies! ...but I
think the example should be obvious, and btw. surely not unusual. I
think that such an app is very well suited for being implemented as a
*rules-based solution*, isn't it?<br>
<ol>
  
<li>Is Tohu appropriate for implementing this scenario?<br>
    <br>
  
</li>
  
<li>If so, how could I realize this scenario with Tohu??? I.e.,<br>
2.a&nbsp;&nbsp; Which app artifacts are necessary and what are their contents?
(pls, see also 2.b)<br>
2.b&nbsp;&nbsp; Could you please outline the app design and provide some code
snippets, or <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; at least point me to a comparable ecommerce example (so that I
can start as <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; soon as possible with the actual more complex biz logic)???<br>
    <br>
  
</li>
  
<li>Would it be hard to turn the result (fixed/static impl) into a
dynamic solution, i.e. one with an "admin ui" for specifying the
required artifacts declaratively via forms or in a graphical manner???<br>
    <br>
  
</li>
  
<li>If not answered yet: Is GWT2 supported as frontend technology?<br>
  
</li>
</ol><br>
Please, I'd really need these issues clarified for being able to take
further decisions. <br>
I'd also appreciate any additional hints or suggestions and thank you a
million for your support in advance.<br><br>
Best regards,<br>
&nbsp; Martin<br><br><br>
<font face="Courier New,Courier,monospace" size="3">_______________________________________________<br>tohu-users mailing list<br>tohu-users@lists.jboss.org<br><a href="https://lists.jboss.org/mailman/listinfo/tohu-users">https://lists.jboss.org/mailman/listinfo/tohu-users</a><br></font>
</blockquote><br></div></FONT>
Attention:
This email may contain information intended for the sole use of
the original recipient. Please respect this when sharing or
disclosing this email's contents with any third party. If you
believe you have received this email in error, please delete it
and notify the sender or postmaster@solnetsolutions.co.nz as
soon as possible. The content of this email does not necessarily
reflect the views of Solnet Solutions Ltd.