My bad. Please bug me if thoughts are still not clear. inline...
On 2012-04-19 14:40, Tom Trenka wrote:
Have to be honest, Sasha...I have a very hard time trying to
understand what you are trying to say. Can you be clearer about your
To be evangelist :) As you noticed I am not doing much contribution.
Just backing the DTK user interest. Trying to fill missed ideas.
In current thread I am responding on mixing JS with back-end PHP.
While there is a complain on using PHP, there was no solution given by
JS on heavy grid load ( or I missed it on this thread ).
I am supporting both (JS and back-end) load test data feed. More inline..
On Thu, Apr 19, 2012 at 11:46 AM, Sasha Firsov <suns at firsov.net
On 2012-04-19 09:22, Tom Trenka wrote:
In addition, I'd mention that not all front-end devs have
how data is being served to them. Do you want a library to
an enterprise server team how they need to write their code?
:) No need to answer. But as DTK guys we could give reference
implementation to jump start that part.
As front-end developer on new (sub-)projects I often have a chance to
define back-to-front end protocol. And the best way is to create dummy
data generator(reference implementation) in back-end environment(either
PHP or JSP). Than, having this emulator on hands, back-end guys (often
myself) do the real job, but keeping protocol intact.
My proposal would be a bit more proactive on simulation part.
Simulation of XHR is not an issue, and duplicated 100K times JSON
or XML from JS as well.
This way we are not tight to back-end still able to go over almost
complete chain of delivery.
The volume could be generated on back-end by PHP as done for now in
discussed grid sample or faked by front-end.
The XHR object (perhaps via "load simulator" transport) could do the
heavy data set generation and giving those simulated data to success
This will eliminate the need for PHP still keeping testing code closest
to actual back-end use.
I guess this part was not clear?
The "load simulator" transport does not call back-end but treat URL
parameters to render matching data(paging/sorting/filtering.
In real life always there is a need to get data from back-end and
contributor has no reason to spend extra time for such JS simulators. It
has sense for DTK as framework. To make back-end related test cases
complete, "timeout", "error" of various kinds to simulate different HTTP
response behaviors. Special case is password validation.
As a front-end person working with that library, do you think they
even have that option?
You are right. 50% could not. But another 50% would be happy to get
whatever is given. And the reason would be to have DTK "standard"-
Be great on most popular (PHP, jsp, asp).
Just stating that for populist reasons DTK should give reference
implementation on most popular platforms, not just PHP.
Those sample implementations would work with DTK components.
Often after some changes as on back-end as on front-end it is difficult
to guess what tier messed up application.
Switching to URLs with "approved" reference app tests will allow to
expose what tier is broken. (Front-end should work with ref impl.)