Forums

I think I can, as an average joe, with production applications on Y.App, counter some of these points.

First, a background on my applications. One is actually quite similar to PhotosNearMe, in that it interacts purely with a web-service layer and does not map to any databases in a CRUD system. It does, however, send writes upstream to web-services. It also aggregates several web-services together in the view (imagine loading photos for multiple places at once, that is the closest).

The App Framework has worked splendidly for this. However, all it's done is given me a good framework in which to write some non-trivial code.

I would say that if you have an application scenario where you can perform all work on the server and you do not need, or want, client side behaviors or interactions, then you should do that.

However, modern applications (especially "app" style) are different. They use techniques like pjax, or more importantly, updating single models and having those changes update accordingly. This makes sure that the page is in sync with a server.

Also, having worked at Amazon I can tell you that there are JavaScript and client-side construction, but using progressive enhancement techniques as well as only providing functionality to clients that have JavaScript enabled. Most of this is visible in community portions of the site.

Even having said that, page construction for a site like Amazon happens asynchronously. It's not something that a typical site can do. It's very large and has a very steep learning curve, like most things that break out of the standard.

So, instead of a convoluted JavaScript framework, they have a convoluted application framework that spans between Perl, Java, C and several other tools.

I think that you are misguided in trying to compare Y.App to a Mobile framework. It isn't.

For myself, as a non-Yahoo Average Joe corporate and independent application developer, here is what Y.App is:

1. A way of constructing a better client experience by creating easy to understand event tables to determine interaction.

2. way of structuring my client side code in a way that makes it easier to navigate and understand. It's also a way of reducing code and having a sensible convention.

3. A way of modeling my data in a way that makes sense in a client-specific environment.

4. A method that easily enables pushState to increase performance, especially in a mobile environment, between page views while internal to an application.

What it isn't:

1. A method for easily writing a mobile framework.

2. A replacement for a backend against an API.

3. Any type of API like REST. People seem to think it is.

Trying to write something under PhoneGap hasn't been done as far as I know. YUI may help you, I have no idea.

It's important to not think you are on your own. You may be a pioneer, but the YUI community is helpful and responsive.

By the way, I used the event-table idea from Y.View in my own gallery-makenode and used my own Y.substitute -based templating there as well (before handlebars was available in YUI) so, I have to admit, no, I'm not completely unfamiliar with Y.App.

I may be missing the point, but Y.Model seems to me that it should be talking to an API and not something that even knows about SQL versus non-SQL.

Doing anything else seems like it would be a challenge for many different reasons.

I do not quite understand why Y.App is automatically associated with mobile. Granted, I should not expect YUI team show how to implement complicated Java server examples with databases.
But I would expect some samples demonstrating YUI widgets in mobile devices. Widgets is where YUI shines. For example, just building an equivalent of Android ListView that allows to pop up a "detail" view would be nice.
What YUI widgets would you use? What CSS would you apply? How would you target such page for both mobile and desktop? What mechanism would you use to switch between views. This is where jQueryMobile really took the initiative. I can find examples of all these cases on jQueryMobile site and just start coding... But I want to use YUI!
I am sure YUI team is in the excellent position to set the best practices, so that "regular Joe" does not have to reinvent the wheel.

JShirley:


I didn't cover this particular question so, here it goes.

In non-SQL databases the main handle to whatever you inserted in it is its Id, which the database generates for you. Thus, if you have an id it is because the record has already been created. This also happens with SQL database when you set an auto-increment primary key field, but in SQL databases this is only an option so, when your table has not opted for such a primary key, the trivial assumption of 'if it has a primary key it is not new' fails. Thus, in an SQL table, the isNew() method of Y.Model might report a record as not new and make you mistakenly do an SQL UPDATE instead of INSERT. Of course, you can somehow get around this, several database engines have a non-standard REPLACE statement that will figure out whether to do an UPDATE or INSERT on its own, however, this should be no excuse to let Y.Model be badly designed.

Also, Y.Model assumes the primary key to be a single field. This, once again, is true for non-SQL database, not necessarily so for SQL tables. My publisher keeps account of their books by their internal number, which is only part of the ISBN number. For them, my book is 0707, which is very easy to handle. Why would they bother with the full 13 digits if, after all, more than half of them are fixed (the issuing authority/country and publisher code is their own) and a few others are for the edition which, for the purpose of royalties, is the same. They still need the full ISBN number, because that is the primary key and is guaranteed to be unique, but they need it broken into several fields for practical reasons. Y.Model does not allow this, the primary key is just one field. Of course you can break it out later on. In fact, you can do plenty of things to work around the limitations of Y.Model but why should you? Why not have a well designed Model that can actually model what's really out there?

Can Y.Model model any of the tables of the SAP system that prints your paychecks, does your invoicing or keeps your inventory? Those tables still give me nightmares. I don't know nowadays, but when I did some customizing some years ago, the table and field names were in German, which I don't speak so I had to have a dictionary at hand and even then made a lot of typos when writing those names. Very few of their tables have auto-increment fields and though most of them have single-field primary keys, lots of them don't.

So, back to the original question of whether you can do CRUD with the app framework, yes, you can, with a non-sql database or a SQL table with a single auto-increment primary key. In many real life tables on existing systems, you have to work around Y.Model to get it done. That is a symptom of a bad design.

This is just in reply to the SQL and non-SQL database question. Y.Model is plagued with several other issues which I hopefully addressed in my own md-model, but you'll have to read that to find out. As I said, I'm not using it myself so md-model might not be complete and my solutions might not be the best but, to my knowledge, it is not blatantly failed.