Openbravo Issue Tracking System - Java Client POS | |||||
| View Issue Details | |||||
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0004341 | Java Client POS | (No Category) | public | 2008-07-08 07:48 | 2008-10-07 11:50 |
| Reporter | lucpmaes | ||||
| Assigned To | |||||
| Priority | normal | Severity | major | Reproducibility | have not tried |
| Status | acknowledged | Resolution | open | ||
| Platform | OS | 5 | OS Version | ||
| Product Version | 2.10 | ||||
| Target Version | Fixed in Version | ||||
| Regression date | |||||
| Regression introduced by commit | |||||
| Regression level | |||||
| Review Assigned To | |||||
| OBNetwork customer | |||||
| Support ticket | |||||
| Regression introduced in release | |||||
| Summary | 0004341: Add AppView to objects passed to BS scripting object + ticket.closing event + dlsystem to Velocity engine | ||||
| Description | I greatly appreciated the new scripting possibilities brought by v2.1 thanks to beanshell. However, I feel the set of objects passed to the scripting engine is somewhat too restrictive. Indeed, as far as I could find out the only way to access the database storage in a way that remains fully under control of OBPos logic in the data access layer is through beans object that are only accessible via the AppView object at run time. As an illustration, I have implemented a "couponing" based customer loyalty system that works great and is highly appreciated on the shop floor by both personnel and clients. In order to do this I of course had for each produced ticket to store the coupon (to enable later retrieval upon redemption). The way I found the nicest was to alter OBPos source code to pass AppView to the scripting engine. Thus allowing the creation of 2 scripts that respectively support the storing of the earned coupon and the retrieval of the coupon at redemption time. These 2 scripts just using the OBPos dataaccess layer in an absolute standrad and clean fashion. This may be seen as not preferable, I do not know, but I believe it is much safer to give script writers the ability to use the dataaccess layer (and keep some form of control and portability) rather than see them anyways find a way to attack the db directly (as beanshell makes also possible but obviously in a much less cleaner way) | ||||
| Steps To Reproduce | |||||
| Proposed Solution | In JPanelTicket (and JPanelButton where relevant) 3 changes: 1. Add parameter to pass to button script m_App m_jbtnconfig = new JPanelButtons("Ticket.Buttons", scriptobjinst,m_App); 2. Add new event ticket.closing (in CloseTicket()) if (ticket.getTicketId() == 0) //only if number was known so far of course { try { ticket.setTicketId(this.dlSales.getNextTicketIndex().intValue()); } catch (BasicException eData) { MessageInf msg = new MessageInf(MessageInf.SGN_NOTICE, AppLocal.getIntString("message.nosaveticket"), eData); msg.show(this); return false; // the hard way... } } if (executeEvent("ticket.closing",new ScriptArg("App", this.m_App)) != null) { return false; // script asked for execution abortion may decide to perevnt clsoing instead ---> probably better } 3. Add parameter to pass system datalayer to scritping engine (in printTicket()) script.put("dlsystem",dlSystem); to enable scritping as #set( $validity = $dlsystem.getResourceAsText("coupon.validityshort")) I could happily share that on repository but I do not know how to do it. Cheers | ||||
| Additional Information | |||||
| Tags | No tags attached. | ||||
| Relationships | |||||
| Attached Files | |||||
| Issue History | |||||
| Date Modified | Username | Field | Change | ||
| 2008-07-08 07:48 | lucpmaes | New Issue | |||
| 2008-07-08 07:48 | lucpmaes | sf_bug_id | 0 => 2013155 | ||
| 2008-10-07 11:50 | adrianromero | Status | new => acknowledged | ||
| 2012-11-07 09:40 | priyam | Category | 01 - General => (No Category) | ||
| There are no notes attached to this issue. |