Anonymous | Login
News | My View | View Issues | Roadmap | Summary

View Issue DetailsJump to Notes ] Issue History ] Print ]
TypeCategorySeverityReproducibilityDate SubmittedLast Update
feature request[Java Client POS] (No Category)majorhave not tried2008-07-08 07:482008-10-07 11:50
ReporterlucpmaesView Statuspublic 
Assigned To 
PrioritynormalResolutionopenFixed in Version
StatusacknowledgedFix in branchFixed in SCM revision
ProjectionnoneETAnoneTarget Version
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product Version2.10SCM revision 
Regression date
Regression introduced by commit
Regression level
Review Assigned To
Regression introduced in release

0004341: Add AppView to objects passed to BS scripting object + ticket.closing event + dlsystem to Velocity engine

DescriptionI 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)
Proposed SolutionIn 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
           catch (BasicException eData)
                    MessageInf msg = new MessageInf(MessageInf.SGN_NOTICE, AppLocal.getIntString("message.nosaveticket"), eData);
                    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())


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.
TagsNo tags attached.
Attached Files

- Relationships Relation Graph ] Dependency Graph ]

-  Notes
There are no notes attached to this issue.

- 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)

Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker