CC Hardware
Has anyone gotten things like Ingenico, Equinox, or Verifone credit card readers to work with OFBiz ? Seems it would need a POS app, so I'm guessing not. How about the Topaz signature pads that a lot of banks use? I grabbed a model number last time I was near one, T-L462-HSB, but I don't know if that model is new or ancient.
Re: [DISCUSSION] Improving the OFBiz User Interface
+1 It'd be way easier to create a template. On 07/31/2017 01:25 PM, Jacques Le Roux wrote: I totally agree Deepak! Our problem is not that we are not using an UI framework or another. Our problem is that we are not consistently generating HTML because we use too much Freemarker templates in the backend. IMO we should always (OK as much as possible, but trying really hard) generate HTML with form widgets. Using Freemarker templates in frontend (eg ecommerce) is another case and we have different types of themes for this reason. If we consistently generate HTML using form widgets (I don't say that that could not be improved too) then it's easier to use CSS on it and choose an UI framework to apply on it. To summarise: consistent generated HTML is the key here Jacques Le 06/07/2017 à 07:49, Deepak Dixit a écrit : IMO instead of thinking to support different UI framework we can define our standard html and then write css based on it. If anyone want to plug different UI framework then user can create new template file and and set it in widget.properties. Thanks & Regards -- Deepak Dixit www.hotwaxsystems.com www.hotwax.co On Thu, Jul 6, 2017 at 1:48 AM, Michael Brohl wrote: I'm currently twisting my had around the question of theme compatibility. The current theme set and the html code (freemarker templates and the code produced by forms and widgets) correspond with each other (naturally). So if we want to introduce a new CSS framework like Bootstrap, we will have to follow it's CSS reference and introduce it's CSS classes to the html and forms/widgets code. This will surely break the other themes. So we have to (1) either find a way to remain compatible with the old themes or (2) decide to break the old themes (and remove them). (1) would mean that we (I cite myself) will need a new approach to be able to "plug in" different UI frameworks. We'll need a UI layer who represents the screen contents in an abstracted way (possibly an enhanced Freemarker macro library) and make it possible to generate HTML code with the right css attributes for the target library. (2) would mean that we will have only one first theme for a time (I'm sure that others will follow more quickly because of using a standard CSS framework) If I look at the Odoo approach [1], it seems that they are not compatible with different frameworks but have their base template build mainly on Bootstrap and jQuery. I still think that maintaining an abstract layer for different frameworks or "theme languages" is too much a burden for us. But will the community agree upon (2)? I might be wrong with my assumptions as I am not an expert (just interested in a much better UI) so I appreciate the community's feedback on this. Thanks and best regards, Michael [1]https://www.odoo.com/documentation/10.0/howtos/themes.html Am 04.07.17 um 20:53 schrieb Taher Alkhateeb: I agree with Michael, baby steps for the win. I propose we perhaps just postpone "big ideas" for now and focus on things that can get results quickly to put life back into this initiative. Maybe next actions could be the following: - Create a base theme - Move all artifacts from framework/images to the base theme (jquery, bootstrap or whatever already exists) and do the rewiring. Also look for any web artifacts anywhere and move them to the base theme. Essentially, remove any thing that is web-based and centralize it in the theme. - Create an implementation theme on top of the base theme Once the above is done, then we can have a discussion of what to do next. There are _many_ ideas, but I will restrain myself this time until we get some action first :) On Tue, Jul 4, 2017 at 6:31 PM, Jacques Le Roux wrote: Le 04/07/2017 à 16:57, Michael Brohl a écrit : Hi James, thanks for your suggestions. As far as I know, JSF would introduce some new technologies because it relies on beans and JSP's (correct me if I'm wrong). I'm not sure if we want to go so far. Facelet is now the recommended technology for JSF https://stackoverflow.com/questions/2095397/what-is-the-diff erence-between-jsf-servlet-and-jsp and both are parts of JavaEE. I agree with Michael and would not like to change OFBiz widgets for JSF. Not that I don't like nor trust JSF (and Oracle, but then a bit less), but the work is overwhelming and obviously we don't have the resources for that. I digged a little deeper into the UI stuff, templates and theming and have to correct my summary a bit: I mentioned AngularJS and Bootstrap on the same level which is like comparing apples and oranges. AngularJS is a client-side JavaScript framework to build single page applications, icluding his own model-view-controller mechanism while Bootsrap is a CSS framework which provides comprehensive UI elements in a structured way. I guess that the use of Angular would need a whole lot more changes in OFBiz than the use of Bootstrap. So I tend to think that we have t
Re: Remove as much as possible delete and remove services
Hi Rishi , all I guess Deepak makes sense so let's defer what I said for now and focus on the renaming effort. I'll start another thread at a future point in time On Aug 2, 2017 12:29 PM, "Rishi Solanki" wrote: > Taher, Are you proposing to move only crud services or crud and basic > services or all. Asking this to understand the exact proposal. > > +1 Deepak to keep the work independent. > > > -- > Rishi Solanki > Sr Manager, Enterprise Software Development > HotWax Systems Pvt. Ltd. > Direct: +91-9893287847 > http://www.hotwaxsystems.com > www.hotwax.co > > On Wed, Aug 2, 2017 at 2:22 PM, Jacques Le Roux < > jacques.le.r...@les7arts.com> wrote: > > > +1 > > > > Jacques > > > > > > > > Le 02/08/2017 à 10:44, Deepak Dixit a écrit : > > > >> Hi Taher, > >> > >> I think we can keep both work independent, as it will be very messy if > we > >> do renaming/cleaning and movement in single shot. > >> > >> Thanks & Regards > >> -- > >> Deepak Dixit > >> www.hotwaxsystems.com > >> www.hotwax.co > >> > >> On Wed, Aug 2, 2017 at 1:44 PM, Taher Alkhateeb < > >> slidingfilame...@gmail.com> > >> wrote: > >> > >> Hi Paul, no what I meant is a new single component where move all > >>> services to it. The reason I suggested that is to reduce "mass > >>> operations" and make them into one. > >>> > >>> Our services require a lot of cleanup, renaming, fixing, etc ... so I > >>> guess I just rushed an email which I wanted to carefully write in a > >>> more comprehensive thread, but I'm just not sure if people are > >>> interested in going that route > >>> > >>> On Wed, Aug 2, 2017 at 10:24 AM, Paul Foxworthy > >>> wrote: > >>> > On 2 August 2017 at 16:37, Taher Alkhateeb < > slidingfilame...@gmail.com> > wrote: > > If you are willing to make the effort towards > > naming all these services then you might as well consider unifying > > them. > > > > Hi Taher, > > Are you proposing one expire service for all entities, which sets the > thruDate attribute? > > If I understand you right, what would we do for entities without a > thruDate? How would we define the expected paramaters, when primary > keys > vary between the different entities? > > Cheers > > Paul > > -- > Coherent Software Australia Pty Ltd > PO Box 2773 > Cheltenham Vic 3192 > Australia > > Phone: +61 3 9585 6788 > Web: http://www.coherentsoftware.com.au/ > Email: i...@coherentsoftware.com.au > > >>> > > >
Re: Remove as much as possible delete and remove services
Taher, Are you proposing to move only crud services or crud and basic services or all. Asking this to understand the exact proposal. +1 Deepak to keep the work independent. -- Rishi Solanki Sr Manager, Enterprise Software Development HotWax Systems Pvt. Ltd. Direct: +91-9893287847 http://www.hotwaxsystems.com www.hotwax.co On Wed, Aug 2, 2017 at 2:22 PM, Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: > +1 > > Jacques > > > > Le 02/08/2017 à 10:44, Deepak Dixit a écrit : > >> Hi Taher, >> >> I think we can keep both work independent, as it will be very messy if we >> do renaming/cleaning and movement in single shot. >> >> Thanks & Regards >> -- >> Deepak Dixit >> www.hotwaxsystems.com >> www.hotwax.co >> >> On Wed, Aug 2, 2017 at 1:44 PM, Taher Alkhateeb < >> slidingfilame...@gmail.com> >> wrote: >> >> Hi Paul, no what I meant is a new single component where move all >>> services to it. The reason I suggested that is to reduce "mass >>> operations" and make them into one. >>> >>> Our services require a lot of cleanup, renaming, fixing, etc ... so I >>> guess I just rushed an email which I wanted to carefully write in a >>> more comprehensive thread, but I'm just not sure if people are >>> interested in going that route >>> >>> On Wed, Aug 2, 2017 at 10:24 AM, Paul Foxworthy >>> wrote: >>> On 2 August 2017 at 16:37, Taher Alkhateeb wrote: If you are willing to make the effort towards > naming all these services then you might as well consider unifying > them. > Hi Taher, Are you proposing one expire service for all entities, which sets the thruDate attribute? If I understand you right, what would we do for entities without a thruDate? How would we define the expected paramaters, when primary keys vary between the different entities? Cheers Paul -- Coherent Software Australia Pty Ltd PO Box 2773 Cheltenham Vic 3192 Australia Phone: +61 3 9585 6788 Web: http://www.coherentsoftware.com.au/ Email: i...@coherentsoftware.com.au >>> >
Re: Remove as much as possible delete and remove services
+1 Jacques Le 02/08/2017 à 10:44, Deepak Dixit a écrit : Hi Taher, I think we can keep both work independent, as it will be very messy if we do renaming/cleaning and movement in single shot. Thanks & Regards -- Deepak Dixit www.hotwaxsystems.com www.hotwax.co On Wed, Aug 2, 2017 at 1:44 PM, Taher Alkhateeb wrote: Hi Paul, no what I meant is a new single component where move all services to it. The reason I suggested that is to reduce "mass operations" and make them into one. Our services require a lot of cleanup, renaming, fixing, etc ... so I guess I just rushed an email which I wanted to carefully write in a more comprehensive thread, but I'm just not sure if people are interested in going that route On Wed, Aug 2, 2017 at 10:24 AM, Paul Foxworthy wrote: On 2 August 2017 at 16:37, Taher Alkhateeb wrote: If you are willing to make the effort towards naming all these services then you might as well consider unifying them. Hi Taher, Are you proposing one expire service for all entities, which sets the thruDate attribute? If I understand you right, what would we do for entities without a thruDate? How would we define the expected paramaters, when primary keys vary between the different entities? Cheers Paul -- Coherent Software Australia Pty Ltd PO Box 2773 Cheltenham Vic 3192 Australia Phone: +61 3 9585 6788 Web: http://www.coherentsoftware.com.au/ Email: i...@coherentsoftware.com.au
Re: Remove as much as possible delete and remove services
Hi Taher, I think we can keep both work independent, as it will be very messy if we do renaming/cleaning and movement in single shot. Thanks & Regards -- Deepak Dixit www.hotwaxsystems.com www.hotwax.co On Wed, Aug 2, 2017 at 1:44 PM, Taher Alkhateeb wrote: > Hi Paul, no what I meant is a new single component where move all > services to it. The reason I suggested that is to reduce "mass > operations" and make them into one. > > Our services require a lot of cleanup, renaming, fixing, etc ... so I > guess I just rushed an email which I wanted to carefully write in a > more comprehensive thread, but I'm just not sure if people are > interested in going that route > > On Wed, Aug 2, 2017 at 10:24 AM, Paul Foxworthy > wrote: > > On 2 August 2017 at 16:37, Taher Alkhateeb > > wrote: > > > >> If you are willing to make the effort towards > >> naming all these services then you might as well consider unifying > >> them. > > > > > > Hi Taher, > > > > Are you proposing one expire service for all entities, which sets the > > thruDate attribute? > > > > If I understand you right, what would we do for entities without a > > thruDate? How would we define the expected paramaters, when primary keys > > vary between the different entities? > > > > Cheers > > > > Paul > > > > -- > > Coherent Software Australia Pty Ltd > > PO Box 2773 > > Cheltenham Vic 3192 > > Australia > > > > Phone: +61 3 9585 6788 > > Web: http://www.coherentsoftware.com.au/ > > Email: i...@coherentsoftware.com.au >
Re: Remove as much as possible delete and remove services
Hi Paul, no what I meant is a new single component where move all services to it. The reason I suggested that is to reduce "mass operations" and make them into one. Our services require a lot of cleanup, renaming, fixing, etc ... so I guess I just rushed an email which I wanted to carefully write in a more comprehensive thread, but I'm just not sure if people are interested in going that route On Wed, Aug 2, 2017 at 10:24 AM, Paul Foxworthy wrote: > On 2 August 2017 at 16:37, Taher Alkhateeb > wrote: > >> If you are willing to make the effort towards >> naming all these services then you might as well consider unifying >> them. > > > Hi Taher, > > Are you proposing one expire service for all entities, which sets the > thruDate attribute? > > If I understand you right, what would we do for entities without a > thruDate? How would we define the expected paramaters, when primary keys > vary between the different entities? > > Cheers > > Paul > > -- > Coherent Software Australia Pty Ltd > PO Box 2773 > Cheltenham Vic 3192 > Australia > > Phone: +61 3 9585 6788 > Web: http://www.coherentsoftware.com.au/ > Email: i...@coherentsoftware.com.au
Re: Remove as much as possible delete and remove services
On 2 August 2017 at 16:37, Taher Alkhateeb wrote: > If you are willing to make the effort towards > naming all these services then you might as well consider unifying > them. Hi Taher, Are you proposing one expire service for all entities, which sets the thruDate attribute? If I understand you right, what would we do for entities without a thruDate? How would we define the expected paramaters, when primary keys vary between the different entities? Cheers Paul -- Coherent Software Australia Pty Ltd PO Box 2773 Cheltenham Vic 3192 Australia Phone: +61 3 9585 6788 Web: http://www.coherentsoftware.com.au/ Email: i...@coherentsoftware.com.au
