Paradox Community

Items in pnews.paradox-dos

Subject:Re: Qbe date parse results - final?
Date:Wed, 18 Apr 2018 00:17:55 +1000
From:Bernie van't Hof <berniev@bje.com.au>
Newsgroups:pnews.paradox-dos
The reason for my js comments is that functionality at the browser client will be by some sort
of js-based software be 
it a framework or whatever.

The proportion of the app that is client-based is a design variable.

In my project I originally envisaged the bulk of the app running on the server, communicating
with some sort of simple 
glass teletype on the web client. Not very efficient perhaps, but given the nature of the project
I really didn't care.

It is obvious that enhancing the IO in the browser client is a no-brainer. But then adding more
business logic becomes 
attractive etc etc.

In the last few years we have seen an explosion of ways to move more and more of the app to
the client. This makes sense 
as it lightens server load and reduces duplication eg validation. However it also creates security
implications and 
exposes source code. All that xml based stuff has disappeared. Micro services on the rise.

My point re js is that it will be difficult for me to move application logic to the client simply
because I am hopeless 
at js. This means the client end will have to be as simple as possible.

I recall Martin Fowler quite some years ago stating that the language to learn was javascript.
Maybe I should have 
listened to him!

On 17/4/18 12:32 pm, Larry DiGiovanni wrote:
> Bernie:
> 
> No, you probably can't layer on Javascript data binding into an existing stack, at least
not easily.
> 
> You could modify your PHP code to follow a web services pattern.  I suspect there are
web service patterns that support 
> Websockets and have Javascript frameworks that support data binding - at least via plug-ins.
> 
> I have built apps using AngularJS.  I was dragged into it kicking and screaming by my
colleagues.
> 
> I like Angular, in that I can move lots of functionality to the server.  But the REST
API is stuck in the 
> request/response model.  There may be plug-ins for websocket support with AngularJS and
Angular.io.
> 
> Angular does not directly handle type checking.  If I pass in a 'customer' type that has
no 'address2' field, it'll 
> consider address2 as null.  I don't like this.  It also does not directly enforce domain
constraints.  If I pass in 
> 'employee.hireDate' as 'Fred', Angular is happy with that, unless the code (or some widget)
tries to use this as a 
> Date.  This sort of thing has been a source of holy wars with said colleagues.
> 
>> My original choice of php similarly reflects my age, knowledge and experience. In hindsight
it
>>  have been better to go javascript right from the beginning but for all the reasons
above that did not happen.
> 
> Just to clarify, this is not about PHP vs Javascript.  You can write your web service
API in PHP, probably leveraging a 
> lot of the code you already have.
> 
>> So... back to the current issue. How to implement a client side UI, without throwing
the entire app to the client.
> 
> Not sure what you mean by 'throwing the entire app to the client'.
> 
>> It would be nice to get some help on the js side though.
> 
> You can still use Javascript, obviously.  It's simple to implement popup dialogs and widgets
in CSS and Javascript.  
> Also, most Javascript frameworks have drop-in widget libraries that are independent of
the framework.  JQuery is a 
> treasure trove of widgets.
> 
> The original post in this sub-thread had more to do with my vision for implementing strategies
I am familiar with for 
> application conversion.  I am still happy to help you pursue your vision if I can.  I
just don't have a handle on an 
> approach, at the moment.
> 
> DISCLAIMER: I am far from a Javascript expert.  I do not like writing Javascript.  I
actually gravitate towards those 
> Javascript frameworks I do use for the simple fact that they do not require a lot of Javascript,
because I do not like it.
> 
> -- 
> Larry DiGiovanni
> 


Copyright © 2004 thedbcommunity.com