Upshot helper extension using Linq To Sql - linq-to-sql

This is my first question on SO, so please bear with any mistakes/irregularities.
I wanted to implement SPA for my new project, Hence I reached Steve Sandersion's after some googling blog.
Looking at the code hosted on github, I noticed that I had to use EF to use Upshot, but my DAL is already written in Linq to Sql, which will be very tiresome to migrate to EF.
So my questions are as below
Has anyone successfully used upshot with L2S? If yes some example would help.
Is there any other way to implement the SPA without upshot so that I can reuse my DAL in L2S?
Edited
I just found today that this question stands useless, as using upshot will not be feasible. Microsoft has stopped working on Upshot.Some one please close this question.

I don't think it is possible. Microsoft has made it sure that people using Linq-to-sql don't survive.
Better use something like jquery and web api with some js mvvm libraries.

As far as I know this should be possible. When using upshot you don't need to use entity framework, you can do the wireing for your self.
In my ria 4 html demo, I make use of ria services to get the data from the server to the upshot client. This way it doesn't depend on the DAL you have. Ria services works by conventions, meaning insert, update and remove methods are present on every domaincontext and you can implement them as you want. For more info you can read this blogpost on setting everything up. And this on for the CRUD operations.

Related

Login/Registration using scala

Just wondering if when creating a login/registration web page using scala is very similar when doing with PHP/HTML which I have used in the past. I've just decided to start learning scala and am a total beginner with no clue. With PHP/HTML, I would use a form, 'POST' method and then the appropriate my_sqli prepared statement insertion and selections. Is it similar or very different in terms of overall methods and way about going with it (obviously excluding the minor differences in syntax). How and in what ways is it different or similar? thnx
Scala is totally different from PHP. Finding connections between them is really hard. I would say that Scala is better in every way but bashing PHP is just too easy nowadays.
I would suggest you to give a look at Scalatra, arguably the most mature among simple web frameworks in Scala. Every framework works differently but you can get an idea of how you think and write code in Scala giving a look at Scalatra examples.
Also, if you never worked on a JVM, it will take a while before being able to properly develop logic in your code. There are many things to learn about the environment (and obviously about the language too) before being able to develop a web app. My suggestion is to first spend some time studying the language and only then begin approaching web development. If you need a language that you can pick up and start writing code, Scala is not the right choice.

Implementing breeze on nodejs with a restful API

We've recently made the decision to move away from .NET and SQL on our backend and rather implement a nodejs solution with either MySQL or postgreSQL. My server guys are putting a standard restful API in place using sequelize as the orm middleware.
Does anyone have any experience in implementing breeze in such a scenario? I understand that I'll have to define the client metadata by hand, but once this is done, do I lose any of the functionality that breeze offers in a typical .NET implementation using the EFContextProvider and server generated metadata? Also, can I use a standard restful API call, or is additional configuration required on the server side?
I think this is an exciting approach.
Breeze does not (yet) offer node-ware for this scenario. You'll have to decide what features of the ContextProvider you like and port them to node. I don't think that has to be super difficult and we'd love to help where we can. This would be a terrific contribution to the community.
What you are looking for in "a standard restful API" will determine many of your design decisions. Do you want to support OData style queries so that client code can compose queries? Or will you take a different approach?
Do you intend to have separate PUT, POST, MERGE, and DELETE calls for each resource? Or will you have some notion of "change-sets" for combining multiple save operations in a single transaction? Something in between?
Breeze favors a change-set approach out of the box. OTOH, if you want to go "straight" REST, there are RESTy Breeze dataservice adapters that suit that style with more on the way.
You can could learn a lot about the mechanics of query and change-set saves in Node by looking at how we handled them in the "breeze-mongodb" npm module referenced in the Zza sample for Node + Mongo.
Take a look at our MongoDB example. This is the breeze client talking to a Node/MongoDB backend. It's not exactly what you are looking for but it does should how one can build a Node backend to talk to Breeze. Also feel free to contact breeze#ideablade.com about consulting in the event that you need help with or want us to implement such a backend.
As a note there are now several samples on Github using node server / breeze / [mysql|postgresql|etc...]
Docs explaining -
http://breeze.github.io/doc-node-sequelize/
Related repositories -
https://github.com/Breeze/breeze.server.node

Bestpractice: Annotation-based ORM frameworks like Hibernate for Adobe AIR?

Question
Is there a commonly used framework for AIR that handles mapping objects to and from the built-in SQLite database? An Annotation-based ORM framework that is to AIR what Hibernate is to Java?
Background
We have an AIR application that runs offline. I need to save/restore complex objects to/from the SQLite database. Some of these ValueObjects contain references to other ValueObjects. For example, an Order object contains a Customer object which contains an Address object.
Ultimately, I'd like to add metadata to my objects, like an [Entity] tag and have persistence "just work," with minimal configuration. I could roll my own ORM solution, effectively writing "Hibernate for AIR" myself, but SURELY someone has already done this.
I've read related posts like Best practices for developing AIR Application with SQLite that advocate creating DAO's, Builders and Services. That's a fine solution but, of course, no one wants to reinvent the wheel if it's not 100% necessary.
Candidates
So far, the best I could find is partial solutions. I'll keep a running list here:
SOFA from Matsiya
Technology - seems like it never got off the ground
FlexORM on RIAForge - seems dead, judging by the forum
JazzRecord - is a JavaScript solution that claims to work with Adobe AIR but documentation is sparse
Cairngorm Persistence Library - I hear nothing but bad things about cairngorm & this solution adopts the iBATIS approach, which is not like hibernate
AIR ORM in ColdFusion - not sure if this can be used without coldfusion (if so where do you get cfair.swc)?
Has a framework emerged for this? Specifically, I'm seeking one like Hibernate that uses Annotations/Metatags to map objects to tables. Are one of the candidates above actually acceptable?
What are you using succesfully?
All input is welcome. Thanks!
take a look at FxORM. I worked on a couple of AIR projects with it - it worked fine for quite complex data structure.
Take a look to AS3 SPOd, we use it on a daily basis on a rather large project. No problems so far.

Is there a simple Linq to SQL generator with bi-directional serialization attributes?

I'm trying to find a way to generate Linq to SQL classes with bi-directional serialization attributes. Basically I want a DataMember tag (with an appropriate order) on every association property, not just the ones where the class is the primary key (like the Visual Studio generator and SQL Metal do). I checked MyGeneration, but didn't really find anything that worked for me. I thought the T4 Toolbox was going to be my solution, it would be quite easy to modify it to add the attributes, but I get an exception on the calling side of my WCF service, and I've gotten no response back on the issue. I'm about to try installing CodeSmith and using PLINQO, but I'd prefer something free.
I'm pretty close to just writing my own T4 generator, but before I do that, I was hoping to find an pre-built solution to this rather simple problem first.
I ended up writing my own code generator for our L2S classes. We actually generate two sets of classes. One is a "lightweight" set of entities for client application use. These classes have no L2S plumbing. But they have the full datamember attributes with proper order. Then we have our L2S entities, which are strictly for backend use. This has worked out quite well.
Be careful using PLINQO. I've looked at that product extensively. In fact, much of my code generator is based on the code PLINQO generates. However, they have a "major flaw" (their words) in how they have implemented many to many relationships.
You might want to also look at a product named "Reegenerator".
Randy
This turned out to be the solution to my problem. I had just resigned myself to start researching my own generator when I stumbled upon that. It has a bidirectional serialization option and it works great! Here's a link to the author's bog, which contains a great video example of how to get started.

Essential Dojo

I'm starting to use Dojo; this is (essentially) my introduction to AJAX. We have a Java backend (torque / turbine / velocity) and are using the jabsorb JSON-RPC library to bridge Java and Javascript.
What do I need to know? What is the big picture of Dojo and JSON, and what are the nasty little details that will catch me up? What did you spend a couple of days tracking down, when you started with Dojo, that you now take for granted? Thanks for any and all tips.
The first thing to do is get familiar with the Dojo Object Model. JavaScript does not have a class system so the Dojo toolkit has created a sort of "by convention" object model that works rather well but is very different to how it works in Java for example.
The reason I suggest getting familiar with it is so you can dig into the code base whenever you start experiencing issues. The documentation available has improved significantly over the past year, but every now and then I find myself having to work out a bug in my code by learning exactly how the Dojo code involved works.
Another tip is to make use of the custom build feature which will significantly improve performance once your application is ready.
As a general tip on DHTML programming, use firebug (a plug-in for Firefox). It allows JavaScript debugging, DOM inspection, HTML editing in real-time and a whole lot more. I've become totally reliant on it now when I'm working in DHTML!
Good luck!
I too just dove head first into Dojo, they have a good API documentation at http://api.dojotoolkit.org/. Even Dojo Campus has some good examples of the plug ins.
If you ask me O'Reilly's Dojo: The Definitive Guide is the best Dojo book on the market.
I also would like any tips and pointers from the Dojo masters.
Cheers
Make sure documentation you read pertains to as recent a release as possible, since a lot has changed very quickly in the Dojo architecture.
Also a great way to see how some Dojo or Dijit widget is used is to look at the source code for the tests - for example, the DataGrid has poor documentation but the tests show a lot of use cases and configurations.
Sitepen is a good resource for Dojo articles.
Also, read up on Deferred (andDeferredList), as well as hitch() - two extremely flexible and powerful features of Dojo. SitePen has a great article on demystifying Deferreds.
Check out plugd, a collection of Dojo extensions that make some things more convenient or adds some clever functionalities to the language. It's made by one of the core Dojo authors so it's rather reliable. It even brings some jQuery niceties into the framework.
Some more things: look into data stores, they're very useful and a much cleaner way to handle Ajax. DojoX has a lot of nice ones too, just remember that DojoX ranges in how well documented or how experimental the components are. Learn the differences between dojo.byId and dijit.byId, as well as the HTML attributes id versus jsId (again, Sitepen has an article).
A couple of things that caught me when I started writing widgets where:
[Understand what dojoAttachPoint, dojoAttachEvent, containerNode and widgitsInTemplate do][1]
have a firm grasp of closures,
Get your head around deferreds
understand ItemFileReadStore, ItemFileWriteStore and stores in general
You can look at stores like a ResultSet (sort of) as well you can data bind them to widgets.
With these major concepts you can start to put together some compelling applications.
Generally what I do is I build a JavaScript facade around my service calls and then I will scrub the response into a store by attaching the first callback in the facade, that call back converts the results into a store and then returns it. This allows me to not hard bind my services to Dojo constructs (so I can support mobile, etc.) while also retuning the data from the facade in a format that data aware widgets expect.
As well if you are doing Java service development you my want to look into JAX-RS. I started out using JSON-RPC which became JABS-ORB but after working with JAX-RS I prefer it, as it integrates well with JPA-EJB and JAXB.
First read how to configure Dojo in your application. Try to understand basic structure of Dojo like if we are writing dijit.form.Button or dijit/form/Button it means Button.js resides in dijit/form folder. Try to understand require, define, declare modules of Dojo. This is enough to start Dojo Toolkit.
Very important fact, indulge with your own sample project using Dojo.