Plugging Angular.JS [Javascript] to d3/win Web services

201 views
Skip to first unread message

David Knight

unread,
Jul 11, 2015, 5:27:10 AM7/11/15
to mvd...@googlegroups.com
Hello all,
Been playing in a new sand-box; and getting a few headaches! The easy part has been the d3/win side of this, especially using MVS Tookit; whereby I have quickly and easily created [I think] a web service whih produces JSON data which is an Access report.

So now, I want to consume that resource; and being the masochist I am; have been trying to work with Angular.JS - which feels very much to me like my first day at work in a PICK shop with zero experience! EVERYTHING was hard! But I do think that IF ONLY I can get my head around it; Angular.JS is perhaps one of the better environments. [No flames please, just my current opinion].

Anyhoo; I purchased an intro online course on Angular [quite good actually]; and want to create a simple page which consumes the above-mentioned web service, to grab the data and format it nicely. Now, the online tutorial doesn't get specific about d3 [shock/horror], but their example of consuming a web service was a bit different; and my attepts keep breaking.

So, my question is: can anyone out there either help me with some Angular.JS [Javascript] code fragments which actually consume a d3/win web service, retrieve the data into some object ready to be pulled apart & formatted?

All the samples in the MVS Toolkit doco seem to be java, or C++ of VB; and I can't figure them out.

Otherwise, it's off to support; and it's the weekend here....

Ideas, folks?

Thanks in advance.

David

Wols Lists

unread,
Jul 11, 2015, 5:47:45 AM7/11/15
to mvd...@googlegroups.com
On 11/07/15 10:27, David Knight wrote:
> So, my question is: can anyone out there either help me with some
> Angular.JS [Javascript] code fragments which actually consume a d3/win
> web service, retrieve the data into some object ready to be pulled apart
> & formatted?

Dawn Walthius seems to be into Angular at the moment. Take a look at the
"yesnosql" group - you might find some interesting stuff / help there.

Cheers,
Wol

Dawn Wolthuis

unread,
Jul 11, 2015, 11:27:50 AM7/11/15
to mvd...@googlegroups.com
I am delighted to see this topic here. I am starting with the  MEAN stack, using MongoDB with restful web services, but I have not built into Mongo -- the CRUD, using restful web services, could come from an MV DBMS...in theory. I have "book knowledge" of how to swap out the mongo services for Cache' MV web services and have heard of people doing U2 web services. It should be reasonably easy with jBASE too, I would guess, but I do not know how people write restfull JSON D3 web services. Maybe someone else can speak to that.

If you would like to see what I'm doing, shoot me an email offlist (dw...@tincat-group.com). I documented a high-level look at what I have been working here https://www.youtube.com/watch?v=AdvUqeg7dkI. I am currently in the process of upgrading a proof of concept to Angular 1.4.1. 

--dawn

--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com
To unsubscribe, email to: mvdbms+un...@googlegroups.com
For more options, visit http://groups.google.com/group/mvdbms



--
Dawn M. Wolthuis

Take and give some delight today

Dawn Wolthuis

unread,
Jul 11, 2015, 11:40:50 AM7/11/15
to mvd...@googlegroups.com
Thanks Wol. I have been quiet on the yesnosql list lately, but I am seeing more people subscribe, so I will try to post more. I was hoping for more of a discussion there, but it seems that some folks just want me to blog my progress. I will try to share more of what I'm learning related to using node.js, AngularJS, etc. There is a learning curve, but it seems like a solid direction for line-of-business apps in need of mobile-plus-web software as a service apps.

There are some things that are complex, but other aspects of doing fullstack JavaScript that are very natural for those who have been doing server-side coding. Using the same language for the client and the server-side is very helpful, in my opinion. I would like to hear successes with other alternatives too, but node.js with fullstack JS looks like a really good option for LOB mobile-plus-web apps when compared to many other options.

--dawn

--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com
To unsubscribe, email to: mvdbms+un...@googlegroups.com
For more options, visit http://groups.google.com/group/mvdbms

Tony Gravagno

unread,
Jul 11, 2015, 2:15:08 PM7/11/15
to mvd...@googlegroups.com, david...@matash.com.au
Let's get into specifics and work through How to solve this problem - as a side benefit we should get a solution to your specific challenge.

1) What is the "signature" of your MVST web service? (What does the URL look like and what's the expected inbound/outbound payload?)

2) What specific code are you using to construct the JS client?

With a clear From/To set of targets we should be able to work through it.

With a Google search for "angularjs web service client" there are literally a million hits. Just picking the first one that comes up we see this page:
https://spring.io/guides/gs/consuming-rest-angularjs/
Using the information there, what does and does not apply to what you have tried?
When we find an "impedance mismatch" we can look for another web page that describes your scenario better.

When it comes to web services, the whole point is that it's language-agnostic. The point of examples in three languages is not just to provide copy/paste code but to give the developer a general idea about how a client should be crafted to communicate with a server. We should be able to derive language-specific understanding from those examples.

One problem here is that most of us are not JavaScript people (I've been working with it for about 20 years so I'm OK) and that presents a mental roadblock.

Another issue is working through another tier of abstraction, the Angular library. AJAX used to be a little easier when we had to hardcode everything because we could see exactly what was going on. Now that all of these frameworks do things "for" us we lose a lot of control. This is exactly the reason why ASP.NET MVC evolved from those who used ASP.NET WebForms. WebForms hide the details while MVC puts the developer in control of the details - and thus the developer must accept that responsibility.

Personally I still have not settled on any particular library beyond jQuery. Every library solves specific problems while having its own shortcomings. It's quite circular and frustrating - and they're changing constantly. I've spent a bit of with Knockout and others. One problem I've had as a third-party developer is when a client says "we want you to work with FrameworkX to build a solution". We can't be experts with all frameworks so that immediately disqualifies us from a series of opportunities no matter what else we can bring to the table. We face the same issue when the developer audience is fragmented to coding for specific browsers, specific mobile devices, etc. All of this forces us to be more specialized and that limits our scope. My solution is to be more of a generalist but to try to pick some specialties. This allows me to consult more at a management level, about how this stuff all works, without having to get down to the syntactical level to be useful.

And (yes, there's a point to this) that leads me to my mantra that we as Pick developers do not need to be experts in too broad a scope of technologies if we become better managers. I know many shops where the Pick-focused IT people are in fear of replacement if they don't learn new skills, but if they elevate themselves out of the trees and up to a more forest-level view they might be able to help coordinate the integration of MV with with other technologies rather than accepting personal responsibility for code-level implementation. And this is exactly the theme of a blog I wrote a couple years ago:
http://Nebula-RnD.com/blog/tech/mv/2013/06/let-go.html


HTH
T

Peter McMurray

unread,
Jul 11, 2015, 7:08:20 PM7/11/15
to mvd...@googlegroups.com
Hi It may pay to follow up on the recent Rocket announcements. I am afraid my own efforts have slowed of late due to health but Dawn's efforts are a great start.
Rocket have finally managed to address an engineering request of mine made some four years ago - I do appreciate that now things are settled down between U2 and D3 life can shoot forward at a better pace, thanks to  John Bramley's efforts.
 In particular UTF-8 support is being released over the next few months with Windows due first quarter 2016. I have never understood the C style programmers' devotion to 16 bit which is at best a half-baked solution to Unicode storage. In my opinion they have confused the base system code with the database storage. Unicode UTF-8 is now the de-facto standard for the internet and Angular is used on three quarters of a million sites tested. As Mr Idle puts it "Say No More".
I strongly recommend that people follow the advice in the D3 manual for quite a few years - write small subroutines to do specific jobs and break away from the monolithic program design. I separated out display, data edit and CRUD into Includes 30 years ago so it was not a big leap for me. If the file verification business rules are contained within one Pick basic program then the Angular genius can work their magic and fire off a call in complete safety with the added advantage that small Basic  routines are easier to design and run faster. I can put it no better than Wikipedia
"AngularJS is built around the belief that declarative programming should be used for building user interfaces and connecting software components, while imperative programming is better suited to defining an application's business logic"
One point that confused me for a moment or two - Angular is referred to as "ng"
Editing UTF-8 is a breeze following the same simple rules as JSON - Control codes and mathematics are done in Ascii which is 100% compatible with UTF-8 for the first 128 characters and the rest is simple because UTF-8 characters cannot collide either with Pick delimiters or themselves.
Pick is the 8 bit answer to the data storage of the 21st century.
Good Luck

Dawn Wolthuis

unread,
Jul 11, 2015, 8:57:18 PM7/11/15
to mvd...@googlegroups.com
Take a typical url with


such as:

with a return value of 

{"_id":"12345","first":"John","last":"Calvin","titles":["Grace and Its Fruits", "The Institutes of Christian Religion"]}

With MongoDB, I can do a prototype with node.js on the backend, using javascript, optionally with a library such as mongoose.

With Cache', I can write MV BASIC in methods of classes that extend the Cache' Server Page, with the CSP gateway (an app server) running with Cache' on the backend.  See http://docs.intersystems.com/ens20151/csp/docbook/DocBook.UI.Page.cls?KEY=GSOAP_REST

I do not work with D3, so clue me in on how you would do this.  Thanks.  --dawn



--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com
To unsubscribe, email to: mvdbms+un...@googlegroups.com
For more options, visit http://groups.google.com/group/mvdbms

Tony Gravagno

unread,
Jul 11, 2015, 11:15:14 PM7/11/15
to mvd...@googlegroups.com
Um, wut?

Tony Gravagno

unread,
Jul 11, 2015, 11:26:50 PM7/11/15
to mvd...@googlegroups.com, dw...@tincat-group.com
While I'm familiar with MVST, I don't use it. I do my own web services. Once again, I'm not keen on the DBMS companies building in connectivity and protocols that we can add ourselves. I think it's sort of a crutch to help Pick people avoid the mainstream world. So I'm not the guy to provide clues on this one. Perhaps someone else will volunteer a tutorial.

But to answer David's specific question I think it's important to understand what he's doing that's not working. I think it will be good to use what he is doing as an exercise toward revisions and getting it right.

Nice to see you back here Dawn.

T

Dawn Wolthuis

unread,
Jul 11, 2015, 11:35:07 PM7/11/15
to mvd...@googlegroups.com
Thanks Tony. Well, you asked for a specifics and I think I provided a nice simple spec with a high level road map for how to implement in two different NoSQL/MV environments. The OP is looking for a similar response but related to D3.

If you or anyone else knows how to answer this question, I'm quite sure that would help address David's question. Are you suggesting that you know the answer and do not know how to write it succinctly or that you do not know the answer?  (yeah, you know there is a smile behind that question, but it is a friendly one)

--dawn

--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com
To unsubscribe, email to: mvdbms+un...@googlegroups.com
For more options, visit http://groups.google.com/group/mvdbms

David Knight

unread,
Jul 12, 2015, 12:29:51 AM7/12/15
to mvd...@googlegroups.com
Hi all, as the OP I must apologise. It's Sunday here in sunny Oz, & my daughter needed help moving, so please do not think lack of response means disinterest, or lack of appreciation!

Plan to reply with more detail this evening (my time).

Thanks to all...

D

David Knight

unread,
Jul 12, 2015, 5:16:33 AM7/12/15
to mvd...@googlegroups.com, david...@matash.com.au
Hi Tony,
Let me see if I can do some justice to your question - a very valid one I must say. However; it MAY be a little overkill for me atm. But I'll try...

At this stage; I am learning how to put together a very specific arrangement of elements, and just get it to work. Now, please excuse me if I get terminology wrong; it's my first day at kindy; and all you seniors scare me!

Starting from the d3/win end [coz I choose to, not because I have to] I understand ULTIMATELY the goal [as other have said to do] is to 'break' up the overall app into business logic & rules; which will themselves no doubt sit on top of a possible large number of small, specific subroutines. That is potentially a mammoth task in & of itself; and perhaps worthy of another thread; but for the sake of this discussion let's say "I get it".

Right now, I want to simply 'test' a very rudimentary 'thing' from my existing app, expose it as a web service; and then have some front end 'consume it'. I hear Dawn speak of 'stacks' and I assume this means the 'stack' of all the myriad of layers between the user all the way down to the db and back up again.

In this case [it just so happens] that all I want to test is a simple Access sentence [AQL] which I'd like to have pop up via a browser.

So, I need the AQL, and of course the various files, dictionaries etc - but I have those because they exist in the current app - that's a given.

But I now want that as a web service. Now TG, with the greatest respect; I have to point out that some of us [well, me anyway] would NEVER be able to write this myself, and frankly I don't want to UNLESS I HAVE TO - in which case that becomes a business issue which I'd have to address in my business model - and that is way beyond the scope of this little discussion. Let's just take it as 'read' IN THIS CASE, rolling my own web service is not practical. It is really another discussion, but I do believe in using tools where appropriate; and viola! Tigerlogic/Rocket whomever just decided to write a gee-whiz gizbit which creates web services for me. Pardon the French but WhyTF would I not want to use that [well, I can think of a bunch of reasons, mainly academic ones; but the bottom line for me is it fits the business model of my target clients whom are cost conscious]?

It is called Rocket d3 MVS Toolkit; and I shall speak of that some more [coz Dawn asked] in another post; so I shan't bore everyone right now. Suffice to say; among other things it allows me the quickly and easily create a web URL which is a web service; which when called/accessed/whatever-is-the-right-term returns a nicely structures JSON data structure. You bloody beauty! [Sorrry, got all Aussie on you.]

Now, before someone jumps down my throat & say yeah, but what about passing parameters, what about subroutine calls; etc etc. Yup it does all that, but I'm keeping it simple here: I'm testing a very basic AQL sentence that takes no parameters - it just runs!

So, AFAIK I have the d3 end "up to" a web service created using d3 itself for the AQL [easy, right?]; and then leveraged d3's MVS Toolkit to turn that into a Web service. Now, to answer a specific question: What does the URL look like? Ah, that's where I'm grean, and I may be wrong. But when using MVS Toolkit; it says the "endpoint" is: http://localhost:8181/Inpatient_List


So, this is where I get a little confused. I'd assume it to be the former; but I could be wrong.

Now, moving on; I am using Angular.JS for which I am an absolute bloody-novice; and have taken ONE online course; which was quite instructive since it included an example of consuming a web-service. Now the code fragment they used inside the model was:

$scope.weatherAPI = $resource("http://api.openweathermap.org/data/2.5/forecast/daily", {callback: "JSON_CALLBACK" }, { get: "JSONP" }});

$scope.weatherResult = $scope.weatherAPI.get({ q: $scope.city, cnt: 2 });

Now the Q & cnt in this tutorial are parameters to be passed to the web service' but in my case there is nothing, so my result was $scope.blahblah.get().

Now, if I'm understanding all this correctly, one of the advantages of consuming a web service is that the web-service knows how to get into d3 and do something; in this case run an AQL and send back the data.

The tutorial I'm running suggests an incremental coding approach, and to dump out what was returned to the Chrome console so we can see it:

console.log($scope);

Which did not produce any data; and that's where I got stuck.

So, I'm not sure if this actually answers the question you posed me; but I hope it is not a complete waste of everyone's time.

I'll look at your links after dinner!

Cheers!

David

David Knight

unread,
Jul 12, 2015, 7:21:59 AM7/12/15
to mvd...@googlegroups.com, dw...@tincat-group.com
Hi Dawn,
Now, remember I am FAR from an expert on this; but if I have been paying attention so far; and reading what you are doing; d3 now has the ability to BE the middle tier. That is, it can natively create web services that represent either/or (1) An Access sentence [with passed selection variables &/or (2) a Flash-basic [important!] d3/win subroutine.

I'm told people suggest doing everything via the second method. I've yet to try.

Now, the goop that makes all this magic work is two 'bits' that now come available FREE [yup free] with d3: MVSP - tbh I'm not exactly sure what this is, but I know what it does: it creates a way 'into' d3 from outside so that things like web servers can access d3. Shall we call it a 'pipe'? It talks to an account on d3; which is also named MVSP and in which you can do things like setup d3 users allowed to access things via MVSP, and 'enable' d3 accounts for access. I'm told MVSP operates as a service in Windows, much like the d3vme & ODBC d3 server run as services. The point is: it's a high speed way "in". I donlt know how it works, and probably don't care at this point in time.

Now, the second [free] bit of kit is MVS Toolkit. Sadly I find the naming curious as it sounds much too similar to MVSP and perhaps will lead to some confusion; but MVS Toolkit is a Windows application which has it's own embedded web server that also understands d3 via the MVSP service connector. Further, MVS Toolkit has [as it's name implies, a Toolkit that allows you to create d3 web services which represent either an AQL or a subroutine. Now I'm further told by the manuals that it can serve up SOAP or JSON data; the true concepts of which probably elude me; but my reading & education so far says JSON is the way to go, so I personally choose to ignore SOAP [coz I don't know what it is, and my brain is already leaking trying to grasp JSON, Angular etc!].

So for me; and in keeping with what you stated as your goals: I want to turn my d3 based app into a app that exposes itself totally via web services; which then becomes [in effect] an API set; allowing potentially others [if I publish documentation to go along with it] to create applications. However, I wish to be that creator of applications, using a suitable platform; and for now I choose Angular. I shan't go into my reasons, so lets leave that there for now!

So, the way I see it, if I can get my head around the various 'layers' of all the stacks involved; and what will become the 'best practice' for the creation of all the various layers; I should be able to work out all the various methods to "do" all the things I need such as data entry screens, searches, validation, on screen reporting, validation, security, menuing systems and so on & so on.

Is that enough to go by for now?

Cheers!

David

Tony Gravagno

unread,
Jul 12, 2015, 7:54:12 AM7/12/15
to mvd...@googlegroups.com, david...@matash.com.au
Thanks David. To answer Dawn's question, this is what I was asking for. A focus on David's specific server and then what he was doing on his client side.

I recommend leaving out JS for a while. That complicates the client side. Layering Angular on top of that is a huge tier of confusion that's not required for basic connectivity.

Just paste your query URL into the address bar of your favorite browser and see if you get anything back. If the JSON doesn't render as text you may need to use the browser developer tools to view the inbound payload.

You provided this URL as a sample:

http://localhost:8181/Inpatient_List/Inpatients?attributes=WARD+ROOM+PATIENT.NAME

To me that means:
1) You have a REST query (so you need to tell MVST that this is REST, not SOAP).
2) You have a basic program, maybe Inpatients.sub if you're following examples?
3) That program accepts a single argument, "attributes", usage is input, type is string.
4) You're parsing that on the + signs to get the desired fields, doing a query, and capturing the results.
5) I'd guess you have another argument on the program like "report" with usage output, set to a dynamic array name where you've parsed the results of your query.
6) You've specified your content type as JSON so MVST knows what format you want going out.

So if any of that is wrong then try to work through the dots that we need to connect:  The URL calls to the MVST service, passes in a program name and parameters, those go to a program, the program returns stuff back. Where does that seem to go wrong?

HTH
T

Dawn Wolthuis

unread,
Jul 12, 2015, 10:14:54 AM7/12/15
to David Knight, mvd...@googlegroups.com
Terrific! From your other post it sounds like you have the piece of the puzzle that I don't know and do not have the piece that I am doing, although there are some libraries I use that would not be relevant with d3.

Heading out for much of the day. Let's move the chat on this back to the yesnosql list where you pointed out this thread.

You will have javascript on the front-end, javascript with google's v8 engine in the middle-front (node.js), MVSP in the middle-back and d3 on the back-end. Each of those layers has a piece of the pie.

I have a crud "template" I use for each "endpoint" and related Angular service. There is one piece of that I need to understand better to use for your purposes -- the schema spec'd in the middle-front tier. I use mongoose for that.

--dawn

Sent from my iPad

Kevin King

unread,
Jul 12, 2015, 10:55:44 AM7/12/15
to mvd...@googlegroups.com, David Knight

The only thing I would add to this great discussion is a mention of logging. Be sure you have a log everywhere that data changes hands. At the core this is a plumbing problem so of you know the data is flowing it can free you to focus on other details.

One issue we regularly run into with web services is that there's no data because we didn't set the right variable name in our MV programming. The other issue is the format of the JSON. If it's not well formed anywhere along the path it might be getting discarded.

David Knight

unread,
Jul 12, 2015, 9:51:29 PM7/12/15
to mvd...@googlegroups.com, david...@matash.com.au
Hi Tony,
Thank you, and yes this does help. More a statement of "where" my mindset is at; it did NOT occur to me to simply goto the URL and see what happens! When I do so, I get nicely formatted JSON data. But also it allowed me to play with things:

1. I couldn't understand why MVS Toolkit gave two suggested URL's one with a bunch of parameters; and one with, especially when my test was to always return all of the results of this Access sentence; so I was able to play. I found that:
    1. Leaving all the attributes there OR removing them all produced identical results. Therefore, in my example, I do not need to pass any values via the URL to get what I want. This was how I expected the sample to work, and was confused by the need for the Javascript to have all the values there, as [to me] that sounded like a business rule; which I did not want in my UI. So, at least I know in this case, the web service call can encapsulate all the business rules, as expected.
    2. Second, I found that only submitting certain values in the sequence of fieldnames delimited by plus signs; caused the JSON result to "filter" and only return the data requested. Possibly kinda neat since it would allow the one web service call to only return the bits that specific instance of a Javascript request needed, presumably being slightly more efficient. Particularly if the requerement produced a large data set, of which only certain elements are required. [I may be confuddling terms here, forgive me.]

So, to answer your questions, [as best I can]:

1) You have a REST query (so you need to tell MVST that this is REST, not SOAP).

Yes: when creating the web service via MVS Toolkit; I specified REST - which the manual I believe says it will return JSON. All these acronyms! Does my head in!

2) You have a basic program, maybe Inpatients.sub if you're following examples?

No: not at this time; I am simply letting MVS Toolkit do all the hard work for me. I told the MVS Toolkit to build an AQL web service. It then walked me through the process of building the AQL sentence. For me, that's one of the nice things: because MVS Toolkit 'understands' d3; it can help me build the required request. Now, long term; I suspect all of these d3 web service calls will be defined as subroutine calls; but this is early days for me.


3) That program accepts a single argument, "attributes", usage is input, type is string.

Dunno: As there is no program, I respond with "huh"?


4) You're parsing that on the + signs to get the desired fields, doing a query, and capturing the results.

No: As MVS Toolkit is handling everything, maybe it does - I don't know. But I'm not doing it. See opening comments above in this post. It seems the web service can filter if field names are passed; but again I say: MVS Toolkit is doing that, not I.

5) I'd guess you have another argument on the program like "report" with usage output, set to a dynamic array name where you've parsed the results of your query.

And this is probably the bit where I'm getting stuck, as this is inside Javascript; and the tutorial I'm following using an external www web service is obviously different to what I'm doing. I'm trying to 'translate' their example to a real one for me. Based on the tutorial; it appears there are functions within Javscript that will do that for me, namely - provided the JSON is well structured; it will return the various fields. But I've yet to get to that part ... I want to get the data back into Angular/browser first...

6) You've specified your content type as JSON so MVST knows what format you want going out

I guess so: although I do not know where or if I did?

Dawn Wolthuis

unread,
Jul 12, 2015, 10:40:54 PM7/12/15
to mvd...@googlegroups.com
Great, you have your back-end and middle-back tiers working. 

I asked on the yesnosql list where I put the javascript code I'm using, but I'll ask here whether you are thinking you can get away without a middle-front tier, going directly from your angular front-end to this api? If your web server is on the same server as your test URL here, then you should be able to test it.

By the way, while it is really cool to just navigate around a database using URL's like this (security to be included, of course), if you want to test out a "write" (put/post), you can use a google chrome add-in named postman.

--dawn

--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com
To unsubscribe, email to: mvdbms+un...@googlegroups.com
For more options, visit http://groups.google.com/group/mvdbms

David Knight

unread,
Jul 13, 2015, 12:42:40 AM7/13/15
to mvd...@googlegroups.com, dw...@tincat-group.com
Hi Dawn,

Yes, it seems I do. TBH: I find the concepts and terminology highly confusing; such as "middle-front" and "middle-back"; but ignoring that for the moment; I think I am saying I do not need a "middle". Now, I realise there "IS" a middle, namely the web-server used by MSV Toolkit; which talks to my 'back end' being d3/win via MVSP; so I guess my answer is - Yes, I think I can get away with <whatever> [in this case Angular.js] talking directly to the "middle"; since that "middle" is a portal, | a means of exposure, | a connector to the "thing" which is my app; wherin the business rules are not only encapsulated but hidden. To me, hiding does a number of things: (a) protects my IP; (b) Makes things simple insofar as [theoretically] I can have a Java/Angular/whatever 'expert' write the UI; and finally (c) Appears to be functional across web AND mobile 'applications' [think UI devices??]

Putting this another way, I wonder if this is what you say others are saying about not having a 'middle'? I see this as 'encompassing' the middle and back into one thing: a web service feature set. Rather neat imho. And lastly does the thing I soooo want to keep: the power, flexibility and numerous benefits of d3 over pretty much ANYTHING I've ever played with.

PS: Yes, my dev system is all one PC; and I anticipate my clients will have a 'server' which shall have all the d3/mv stuff on it: d3/win; MVSP and lastly the MVS Toolkit web server component. Where the Angular stuff will site is still a bit of a mystery to me: I suspect it will sit on their internal web server, possible IIS; and if that is not the same as the d3 server; then I'm guessing the URL calls will have to [somehow] become parameterised so the IP address is read from a config file of some sort.

But that's a later story.

D

Tony Gravagno

unread,
Jul 13, 2015, 1:48:21 AM7/13/15
to mvd...@googlegroups.com
This discussion is going in awkward directions so I'll just continue on the path I was hoping to lay out.

Yes, MVST allows you to define a query or a program, so after you clarified that you're using a query rather than a program most of my follow-up to that became invalid. Ok...

As to front/middle/back...
Your front-end is the browser.
When you start to serve up JS/HTML that's going to come from a web server, the middle tier.
Your back-end is D3.
By middle-back, Dawn means the connection from a middle tier to the back-end. This is the connection from the MVST Windows component into D3.
So far the front-middle would be your browser going through localhost:8080 into that component.

When you get the URL querystring to do what you want, it's time to swap out the front-end, and get JS/HTML to make that same connection.

There are two other factors here - HUGE:

First, there are apparently nuances to your MVST configuration. You need to go through the docs to get a good understanding of how that works, and then you'll understand how the data you're putting through it flows. Just play with that part a while until you're completely comfortable.

Second, JavaScript by itself is a skill and Angular on top of that is a skill. Forget about MVST and D3 for a while and just focus on those tools. MVST is irrelevant if you're not sure how to parse a list from a result set and fields from that list. Play with that side for a while and spend some time in Angular forums. If you ask questions I strongly suggest not mentioning D3 or MVST or anything else Pick-related as that will just confuse the responses. You just need to work through samples of getting Any web service to display data in Any web page.

The final step will just be to connect the dots. A firm understanding of what those dots are is critical. That's all I do - I connect dots, and when I don't understand one side I weigh the cost of learning it myself or getting someone else.

That's about as far as I can go, maybe someone else will pick up here.
Regards,
T

David Knight

unread,
Jul 13, 2015, 2:09:01 AM7/13/15
to mvd...@googlegroups.com
Hi Tony,
Thanks you for your reply - much appreciated.

Awkward?? Well, maybe - but I stride on in the vain hope others maybe watching & afraid to ask the same questions...

I appreciate the clarification; and agree with you about learning JS/Angular - sadly I cannot afford to buy in resource; so will have to learn it myself. The forum idea is a good, strong one. Thank you. The MVS Toolkit <--> MVSP <--> d3 part is well documented and I'm pretty sure I've 'got it'; as far as the rules go. As to actually using it in a strong way; that remains to be seen. The corollary is anyone can learn DataBASIC syntax [the 'rules']; but that does not mean they can write good code & well structured applications!

.....

At the risk of making you continue a conversation you want to stop [  ;>)  ]; all was clear except one statement you made...

If the front end is my browser and JS/HTML is the middle tier; then why would I:  "When you get the URL querystring to do what you want, it's time to swap out the front-end, and get JS/HTML to make that same connection" ??

Or do you mean TEST the connection via a browser directly to the web service; and then  ("swap-out the front -end") build via Angular/JS/HTML the UI functionality including accessing the data via the web service? This makes more sense to me. Is that what you meant?

Ta,

David

Brian Speirs

unread,
Jul 13, 2015, 6:00:35 AM7/13/15
to mvd...@googlegroups.com
Hi David,

My interpretation of that comment is:  Web services are not usually consumed by browsers - they respond to applications that may be within your organisation or anywhere in the world. My application will query your web service and be returned "something". That something may be JSON data or an XML package - but there probably isn't any HTML to render in a web browser. So, the web service is all about responding in a certain way when queried with a set of parameters.

So, "swap out the front end" refers to changing your method of querying the web service and receiving the result.

Of course, I may have it quite wrong :-/.

Cheers,

Brian

David Knight

unread,
Jul 13, 2015, 6:58:08 AM7/13/15
to mvd...@googlegroups.com
Hi Brian,
Ok, that makes sense, too. I guess in my particular, rather myopic view; I'm only looking to build a commercial grade app - replacement of my existing d3 app; so my focus is specific. In my case the browser will [mostly] be the consumer of the web services that 'are' the app; in order to generate a browser compatible UI. I say mostly because I also see a need for the same services [not all] to be consumed by mobile-phone-type clients apps. The differences being the mobile phone-type app can [if required] access local resources for improved experience.

Cheers

D

Tony Gravagno

unread,
Jul 14, 2015, 2:23:35 PM7/14/15
to mvd...@googlegroups.com, david...@matash.com.au
Sorry if I was unclear but you guys did understand me. The browser is just a convenient client to test the web service. In addition to the address bar, browsers (via extensions/plugins) now have great tools for viewing the outbound/inbound payloads so you can see exactly what's coming back - and they'll format JSON nicely to see structures as well. You can also use a command-line or any web service testing tool.

The point was to test the web service functionality first, to make sure it works and to get a clear understanding of the data returned. THEN you create a new client which uses tool-specific syntax to make a web service call. Your goal is to get that tool to reproduce what you did in your tests. If you don't get back the same results you know the problem is with the client tools. Nice eh?

Finally, once you have retrieved the data with your client-side tools of choice, you need to populate a UI. This is where Angular comes in as it binds data to controls. For better or worse it's abstracting out the glue code that moves data between variables and user controls. I'd recommend that you hard-code some JSON structures and run them through your Angular code to make sure the UI properly reflects the underlying data.

This is how I do my .NET code too - I write classes which provide test data, I make sure that all works with the UI, and then I just change a flag from Test to Live to see live data flowing to the UI. Again, it's all a matter of connecting dots: You get the server data to the client, and stop. You get test data into the UI, and stop. Then you hit the flag to move the server data all the way through to the UI.

This technique is at the heart of Test Driven Development (TDD), automated generation of mock classes, unit testing, and Model-View-Controller (MVC) development.

All of this stuff is related. And when I suggest that companies contract or hire people with these skills, I'm not just throwing in a sales pitch. Sure, this is my business and I hope people ask me to help with projects like this. But in all sincerity, I'm trying to prepare you for a solid business decision: If you can't do these things on your own within the time frame that the company requires then you need to solve the problem in a different way. Just don't let a project flounder because you can't do everything on your own. That's bad for all of us. It's all a matter of Time, Quality, or Cost. You can get what you need Fast, Cheap, or Good, but not all three. As Mark says, "pick two". Think about that and make sure management is aware of how this works. You are not admitting defeat by calling in resources, you're doing what the company needs to get a job done. There's more job security in that than any number of attempts to get things half-done and months beyond the original time frame.

HTH
T

Kevin Powick

unread,
Jul 14, 2015, 2:56:47 PM7/14/15
to mvd...@googlegroups.com, david...@matash.com.au

On Tuesday, 14 July 2015 14:23:35 UTC-4, Tony Gravagno wrote:
This technique is at the heart of Test Driven Development (TDD), automated generation of mock classes, unit testing, and Model-View-Controller (MVC) development.

Is TDD Dead?

An interesting playlist of conversations from 2014 between David Heinemeier Hansson, Kent Beck, and Martian Fowler.

The gist of the the videos is that nobody denies that testing is important, but TDD works for some people better than others (DHH = No on TDD, KB and MF = Yes). Also, mocking is overrated and overdone; KB and MF do not, or rarely, use mocks. Finally, many people approach TDD incorrectly, thus do it wrong.

--
Kevin Powick



Dawn Wolthuis

unread,
Jul 14, 2015, 5:25:12 PM7/14/15
to mvd...@googlegroups.com
Excellent link! I have colleagues who love TDD and I have never grooved with it. Testing is important, but writing the test first, etc. is a matter of taste. It is even more important to test to requirements. TDD is one way to encode those requirements, but it is at a very low level (away from the user).  --dawn

--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com
To unsubscribe, email to: mvdbms+un...@googlegroups.com
For more options, visit http://groups.google.com/group/mvdbms
Reply all
Reply to author
Forward
0 new messages