Frans,

I wonder if you could comment on your intentions (if any) of building JSON support into the default LLBLGen scripts. (FWIW, personally, I am concerned with SelfServicing.)

September 3, 2008 Here is some interesting work Josh Wright has been doing: http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=12426&HighLight=1 http://www.readingwright.com/Post/Show/LLBLGen-to-JSon http://github.com/JoshWright/llblgen-to-json/tree/master

//Result: 2) //{"BuyerName":"Ben Franklin","Price":49.95, 3) // "Product":{"Name":"Headphones"}, 4) // "Address":{"City":"Oklahoma City", 5) // "State":{"Name":"Oklahoma" 6) 7) order.ToJSon( OrderFields.BuyerName, 9) OrderFields.Price, 10) OrderEntity.Relations.ProductEntityUsingProductId.With( 11) ProductFields.Name 12) ), 13) OrderEntity.Relations.AddressEntityUsingShippingAddressId.With( 14) AddressFields.City, 15) AddressEntity.Relations.StateEntityUsingStateId.With( 16) StateFields.Name 17) ) 1 ) 19) );

19-Jan-2009 Also, Brian Chance has been working on something similar: http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=15124&HighLight=1

So as you can see, the above posts date back to Sep 3/08 and Jan 19/09....here we are now in Aug 2009 and still no comment really from LLBLGen on whether any of these features will be added. To be fair, there really seems to be no huge amount of demand on the forums....but I wonder if this is perhaps somewhat of a commentary on the nature of the work LLBLGen customers are working on, or maybe perhaps the way they are implementing things, as there is no easy way to do some of the sexier new jQuery/AJAX stuff on top of LLBLGen. As for myself, I've been so busy "getting stuff done" the old way, its just fairly recently that I've had the time to start fooling around with the cool stuff like jQuery.

I see there is a new LLBLGen version pending release:

http://www.llblgen.com/pages/roadmap.aspx LLBLGen Pro v3.0 Upgrade of LLBLGen Pro with major and minor feature enhancements and benefits. Existing customers will have the ability to upgrade at a discount. Estimated first beta release date: October/November 2009

v3.0 schedule 1-May-2009 The development of LLBLGen Pro v3.0 is well on schedule. We expect to release the first beta in October/November of 2009. As usual, v2.x customers will be enabled to upgrade at a discount. LLBLGen Pro v3 will have a completely new designer, offering (among many other features) model-first development, fine grained entity and target schema management / mapping and support for our own runtime library framework, NHibernate, Linq to Sql, Entity Framework and other 3rd party O/R mapper frameworks.

Seemingly no mention of Ajax / JSON support or features.

It would seem to me that it would be hugely in the self interest of LLBLGen to implement some features specifically to support the ease and productivity of AJAX development.

At the very least, I think it would be extremely helpful to have on each instance and collection class (self servicing), .ToJson and .FromJson functions (with some appropriate overloads for specific fields or behaviours).

But in addition to that, it would also be nice if LLBLgen could have perhaps some sort of jQuery plugin, to simplify: a) Client calls to send and receive LLBLGen based json data from the server b) client side template binding (I've previously asked about intentions to develop a newer version of the 'ASP.NET 2.0 GUI generator templates (Adapter / C#) ' that is more geared toward client-side Ajax style development.

Also regarding the client side LLBLGen jQuery plugin topic....have you seen this video demonstrating the Google Web Toolkit (GWT) and gQuery(their clone of jQuery)? Very impressive stuff: http://dotnet.dzone.com/videos/video-progressively-enhance

Not to gloss over the technical difficulties of this, or the fact that I'm sure Frans is busy with 3.0, but it would seem to me that this is something that that would have a very high "value to customers/difficulty to implement (for Frans)" ratio...do you disagree?? Not to mention, if it was super slick, it would certainly bring a great deal of grassroots attention to LLBLGen in the blogosphere.

Anyways, Frans, could you please comment on this so people like me know whether this is a direction you intend to move or not?

Thanks!

For v3.0 we have no plans to implement specific serialization support for these kind of frameworks. The main reason is that the deserialization can't be done to llblgen pro entities so one should use for example DTO's to get this working. As one can create DTOs in various ways, we leave that to the user.

Though the main reason is that we're not UI framework specialists, we're data-access specialists. This means that we can't provide proper code for every UI framework out there (silverlight, flash, json, something new ), and rather invest time to get our framework properly suited with all the other features one would want. The same reason we're not including json kind of templates is applied to the fact why we're not including UI templates. We have rudimentary asp.net templates but that's mainly for a basic CRUD editor one can use as a base for some maintenance app, not for real-life LoB applications. Adding methods like ToJSon and FromJSon are meaningless for people who don't use them. In 3.0 there will be a feature (using the settings stuff described below) where you can enable/disable features in the generated code, so we could add these later on in the generated code, but it's not planned for 3.0.

I can understand why you're asking this, though at this point we're not planning to create these templates. That's not saying we won't in the future, but for 3.0 they're not included. What is included in 3.0 is a much better framework for code generation configuration, for example you can define, in an xml file, specific settings for your additional templates, which are then shown to you with entities, but also with the project (for defaults for example). This makes including templates for these kind of frameworks much easier.

If others, who are more specialists in UI frameworks, want to create these templates, all the better, and if we are allowed to distribute these on our website, we definitely will do so.

Hello Otis,

Thanks for the response as I was wondering the same thing. I would like to add to this that it would be really nice to have a way to stop certain public methods and properties from being serialized, maybe using attributes, so that only the public properties that we need get serialized.

An example of this is then when I use json.net to serialize an entity I get properties like entity.CustomPropertiesOfType being serialized and sent over the wire when they are not needed.

It would be handy to have a way of specifying fields not to serialize. I know that Josh Wright's ToJson extension sort of does this the other way by specifying fields which could be included but this causes a problem. The ToJson extension uses the Fields collection to specify which fields to serialize which means that it's not possible to serialize custom properties that have been added into the // __LLBLGENPRO_USER_CODE_REGION_START CustomEntityCode region.

Either way I do this I don't get what I want. I'm either limited to serializing the fields in the Fields collection or I have to serialize everything.

Do you have any thoughts on this problem?

Otis wrote:

For v3.0 we have no plans to implement specific serialization support for these kind of frameworks. The main reason is that the deserialization can't be done to llblgen pro entities.....

Can't be done? Maybe I misunderstand what you mean, but isn't that exactly what is being done in the examples above?

Otis wrote:

Though the main reason is that we're not UI framework specialists, we're data-access specialists. This means that we can't provide proper code for every UI framework out there (silverlight, flash, json, something new ), and rather invest time to get our framework properly suited with all the other features one would want....

I understand this principle, and of course you can't support all UI frameworks perfectly. But is it not true, some UI frameworks are starting to rise to the top. Flash is mostly going down fast (other than for stupid little games), silverlight is kind of treading water, javascript libraries, especially jQuery, are quickly becoming more popular and have what I would say critical mass, as in, they will be around for a loooong time.. From a cost benefit perspective for you, it is likely not a good idea to support everything. But to target Json/ jQuery specifically, I think it would be incredibly beneficial to you. If you could come up with a reasonable framework to facilitate and simplify the plumbing between web client and server data, just as you have done with objects and sql databases, I think it would pay off huge for you. And I am not envisioning anything so complicated as the LLBLGen framework itself....I am talking simpler stuff that gets us 75% of the functionality we want. Look at the examples I posted above...very simple approaches, and it is getting things done for these two guys.

And as for being data access specialists....I've read your blog posts, and you're smarter than 85% of the people writing jQuery plugins, or writing articles on how to use jQuery in an asp.net context. So if you are an expert only in data access, it is purely by choice, not lack of ability.

I would like to say that if you could do something even 10% as good as LLB in the json/jquery area, I would be so happy. So if you are taking a survey for new features after 3.0, put my vote in for this!

tprohas wrote:

Hello Otis, It would be handy to have a way of specifying fields not to serialize. I know that Josh Wright's ToJson extension sort of does this the other way by specifying fields which could be included but this causes a problem. The ToJson extension uses the Fields collection to specify which fields to serialize which means that it's not possible to serialize custom properties that have been added into the // __LLBLGENPRO_USER_CODE_REGION_START CustomEntityCode region.

Either way I do this I don't get what I want. I'm either limited to serializing the fields in the Fields collection or I have to serialize everything.

Do you have any thoughts on this problem?

You could take Josh's code and modify it such that in addition to the Fields specified in the ToJson call, it would also perhaps reflect on the object and include any additional properties marked with a certain attribute? Or, you could make it so ToJson accepts property names as strings?

Ok, a couple of replies into one

tprohas wrote:

Thanks for the response as I was wondering the same thing. I would like to add to this that it would be really nice to have a way to stop certain public methods and properties from being serialized, maybe using attributes, so that only the public properties that we need get serialized.

This is built-in for the ITypedList support for databinding in collections. You can grab all property descriptors by using: collection.DefaultView.GetItemProperties(null);

All entity fields in property descriptor form + all properties which have no Browsable(false) attribute are included. This is the same routine which is used for databinding a view to a grid and auto-discover columns, all properties which should be filtered out are already done so as we've added Browsable(false) to all of them (in case we missed one, please let me know).

Either way I do this I don't get what I want. I'm either limited to serializing the fields in the Fields collection or I have to serialize everything. Do you have any thoughts on this problem?

I hope the call above will give you some insight in how to enable it for json/other custom serialization pipelines.

In v3.0 you can specify extra attributes for fields, navigators, entities etc. inside the designer, and we also will add custom settings so you can disable for example Browsable(false) on single-value navigators. TDL statements can check for setting values so you can add custom setting definitions and then check for the values in your own include template.

trevorg wrote:

Otis wrote:

For v3.0 we have no plans to implement specific serialization support for these kind of frameworks. The main reason is that the deserialization can't be done to llblgen pro entities.....

Can't be done? Maybe I misunderstand what you mean, but isn't that exactly what is being done in the examples above?

What I meant was: you have an entity class instance of CustomerEntity, serialize its contents to e.g. JSON and when you deserialize it, it's inside javascript, so the data isn't deserialized into a CustomerEntity instance in Javascript. That's what I meant . So i.o.w., you can also use the xml serialization and go from there. (Not sufficient for json, I know).

Otis wrote:

Though the main reason is that we're not UI framework specialists, we're data-access specialists. This means that we can't provide proper code for every UI framework out there (silverlight, flash, json, something new ), and rather invest time to get our framework properly suited with all the other features one would want....

I understand this principle, and of course you can't support all UI frameworks perfectly. But is it not true, some UI frameworks are starting to rise to the top. Flash is mostly going down fast (other than for stupid little games), silverlight is kind of treading water, javascript libraries, especially jQuery, are quickly becoming more popular and have what I would say critical mass, as in, they will be around for a loooong time.. From a cost benefit perspective for you, it is likely not a good idea to support everything.

It's a compromise: we create a great o/r mapper designer and ditto framework, and for UI stuff, we try to provide handles / hooks so it's possible to get the data out the framework in the way they want, e.g. build a json serializer. The problem is that if we add ToJSon to our runtime lib, and json isn't going to make it, we're stuck with it. We already provide remoting and xml serialization, which is sufficient for many scenarios and which aren't really tied to a higher level UI layer.

Would we invest time into doing that, we can't invest that time in what we're doing best.

Personally, I don't think Flash will die soon but others think differently, and to allow them to get json / other stuff out of an llblgen pro entity, we would like to help them with hooks/methods which make this possible, but not at the level that the data is serialized in that format but in the way to build these services rather easy. The same is true for astoria for example. Or dynamic data. All kinds of hip technologies which might die off in a year or two or might get big, who knows. If these technologies are impossible to support due to some problem in our framework, we'll fix it.

I know we added support for dynamic data ourselves. This was because it needed internal knowledge of our framework but frankly, is it really that important that we support that?

But to target Json/ jQuery specifically, I think it would be incredibly beneficial to you. If you could come up with a reasonable framework to facilitate and simplify the plumbing between web client and server data, just as you have done with objects and sql databases, I think it would pay off huge for you. And I am not envisioning anything so complicated as the LLBLGen framework itself....I am talking simpler stuff that gets us 75% of the functionality we want. Look at the examples I posted above...very simple approaches, and it is getting things done for these two guys.

True, though as I said earlier, we have no experience with any of these technologies, and to get up to speed with them, I'd rather invest that time in our own framework and provide more lower level facility methods to the people who want these add-on templates/libs. For example if for json a lowlevel method is required to obtain all property descriptors, I'll add it. But not a toJson method, as we can't maintain that, as we have no idea how it works.

And as for being data access specialists....I've read your blog posts, and you're smarter than 85% of the people writing jQuery plugins, or writing articles on how to use jQuery in an asp.net context. So if you are an expert only in data access, it is purely by choice, not lack of ability.

Thanks for the convidence but we're really newbies on th jquery/json level, so before we're up to speed and have a maintainable code base we're at least a month busy with it, which IMHO is something I really don't want to invest at this moment, as the designer has to be finished and shipped.

I would like to say that if you could do something even 10% as good as LLB in the json/jquery area, I would be so happy. So if you are taking a survey for new features after 3.0, put my vote in for this!

Ok. Though would it be a problem if this was a user contribution, which at a lower level gets support from us by framework specific methods which are more generic (e.g. the proprty descriptor routine which is already there) but will help built these add-ons ?

I use http://jsonfx.net/. It works just fine.

Seth wrote:

I use http://jsonfx.net/. It works just fine.

Seth, if you don't mind, could you jot down a quick summary of how this works for you (in general, and within an LLBLGen environment)?

The Architecture and Features pages look interesting, but does a person have to download and mess with it before understanding what it really does?

Presuming you've been reading along in this thread, can this be used to json serialize/deserialize LLBLGen objects and collections? It seems like it has some sort of a client side proxy layer, and some client side templating features.....but hard to tell exactly what it does....

Also, in case any LLBGeners knowledgeable in the whole jQuery/Json realm happen upon this thread.....I am trying to track down some decent articles on how to:

Receive a single complex object from a webservice Receive a collection of complex objects from a webservice Send a single complex object to a webservice Send a collection of complex objects to a webservice

...of course, using jQuery, json, asp.net (using any workable web service technology)

So for now, I'm not even worried about the LLBLGen objects aspect of this, simply figuring out how to do this by serializing a class, collection, or dataset from the server is sufficient for starters.

I use it in an ASP.NET MVC setting with POCO objects. The controller methods take in a json string that I later deserialize like:

AttendanceEntryView[] entries = new AttendanceEntryView[] { };
if ( jsonData.Length > 0 )
{
    JsonReader reader = new JsonReader( jsonData );
    entries = reader.Deserialize<AttendanceEntryView[]>();
    var service = GetService<IClassService>();
    try
    {
        service.SaveAttendance( entries );
        return new JsonResult
        {
            Data = new { Success = true, Message = "Complete!" }
        };
    }
    catch ( Exception error )
    {
        return new JsonResult
        {
            Data = new { Success = false, Message = error.Message }
        };
    }
}
else
{
    return new JsonResult
    {
        Data = new { Success = true, Message = "Nothing to save..." }
    };
}

It then passes the objects over to the service layer which deals in entities and entitycollections. I am actually writing a series of posts on this very subject (custom web controls etc.) on my blog (http://www.sethjuarez.com). I have not quite gotten to this part yet, although it will probably be #4 or #5 in the series.

Presuming you've been reading along in this thread, can this be used to json serialize/deserialize LLBLGen objects and collections?

I personally would not do that, but yes, I don't see why this would not work. At least to an array of entities (which can subsequently be passed into the appropriate EntityCollection<T>'s constructor). The entity should do fine.

It seems like it has some sort of a client side proxy layer, and some client side templating features.....but hard to tell exactly what it does....

I don't use anything other than deserialization and probably serialization (in the future).

Hope I have been clear.