|Subject:||Re: Qbe date parse results - final?
|Date:||Wed, 18 Apr 2018 00:17:55 +1000
|From:||Bernie van't Hof <firstname.lastname@example.org>
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
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.
Maybe I should have
listened to him!
On 17/4/18 12:32 pm, Larry DiGiovanni wrote:
> You could modify your PHP code to follow a web services pattern. I suspect there are
web service patterns that support
> I have built apps using AngularJS. I was dragged into it kicking and screaming by my
> 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 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
above that did not happen.
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.
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.
actually gravitate towards those
because I do not like it.
> Larry DiGiovanni