Morgan: Okay, I'm Brett Morgan.
I'm the developer relations
engineer for Blogger,
and we're here this afternoon
to talk about building
professional web sites
using Blogger as
the back-end infrastructure.
So what are we gonna cover?
Firstly,
why you should use Blogger.
Then we'll look at a couple
of ways of doing so,
and then finally,
we'll have Pat Coleman here
do a live coding exercise
showing you how
one of these approaches
works in practice.
So a question you might
validly be asking--
why would I use Blogger
as a back-end infrastructure
for a web site
that I'm building
to serve myself
or for a client?
So let's start with a--
a reason that kicks it
for me.
Blogger is big, probably bigger
than you'd imagine.
Here's some statistics to help
you get a feeling for that.
We have 400 million active
monthly read--uh, users--
readers.
Um, up from 300 million actives
just a year ago.
Blogger is growing.
We're a truly
international platform.
We're localized
in 50 languages,
and 75% of our traffic comes
from outside the U.S. of A.
And finally,
this is the statistic
that does it for me--
our users are putting
their thoughts, their dreams,
their--their daily
annotations into Blogger
at a rate of 250,000
new words a minute.
This means that Blogger
is truly scalable.
It's stable, and it's
the platform of choice
for millions
of people out there.
I did mention that
we were stable, right?
So what do I--
what do I base this on?
Well, in a recent survey
of, uh,
all of the top
blogging platforms,
uh, our friends over at pingdom
ran a survey,
and Blogger
was the only platform
for the entire survey period
to maintain 100% uptime.
This means that we're stable.
We're dependable,
and you can use us
for both yourself
and for your clients'
web sites.
Now walking back
in history,
I remember the first
administration interface
I handcrafted for my client,
matching him up
with the web site
I was creating for him.
But, you know,
time moves on,
and I learned that
there's more to it
than just figuring out
the mental puzzle.
There's--there's engineering.
There's user interface concerns,
and these days,
I've come to understand
that these things really matter.
I'm showing off Blogger's
new admin interface
that we're currently rolling out
to our--our users.
As you can probably see
in the URL bar, this is draft.
So if you are using Blogger,
you'll start seeing this appear
across all--
everyone coming up.
Now hopefully I've impressed you
to try Blogger out,
and you might be validly asking,
"Okay, how would I do that?"
Let's have a look
at three ways.
First thing, I'd look at
Blogger's templating system.
Then I'd show you what
you can do with JavaScript,
and then finally,
we'll have a look
at the RESTful APIs.
So firstly, templates--
Blogger's templates are solid.
They're stable.
They've been with us
for quite some time.
They're well engineered,
well bedded in.
Let's have a look at one.
This is actually some XML
that's pulled out of
one of my--my blogs--
mouserants.blogspot.com--
slightly simplified, but let's--
let's walk through it
and actually have a look
at what's happening here.
Firstly, we're using
name spaces to demarcate
where our--
the parts of our templating
language is.
The B name space is used
for our conditionals
and for our, um,
modularity,
which you can see
on the screen here,
and it's also used
for looping constructs.
Next, we have
an expression name space,
which here is being used
to calculate
some style for div,
and the third one
is our data name space,
which is used to pull data
out of the underlying
data store.
But what's all this doing?
Well, if a user
is on a mobile platform,
as you can probably tell, this
is serving out the blog header,
serving out
the title of my blog
and the description
underneath it.
And if they're not
on a mobile platform,
well, there's a nice little
image that goes behind that.
As you can see,
our templating language
gives you the ability
to totally, um, customize
the look and feel of your blog.
So once you've created that,
your next question is,
"Okay, I've got this template.
How do I put it into Blogger?"
Well, again back
to our swanky new U.I.
There's a template tab
on the left,
and what you'll see is this,
and if you scroll down
the page--
the red box is not there
on the production.
This is to draw
your attention to it.
Okay, you can do
a couple of things here.
You can download
your current template.
This is useful if you're
making some changes
in the admin interface
that you're not sure
if you're gonna like or not,
so you can download it,
play around,
and then step backwards,
or as in the case here,
where we've created a new one,
turn around and upload it.
Blogger will then validate
what you've uploaded,
and once it is happy
with that,
it will refresh
all your sites,
and everything will be available
in your new library.
So next question is,
what advantages come from
using templates?
Well, our administration
interface
deeply understands
the templating system.
So, for example,
what we're looking at here
is a layout view of my blog
without all the content in it.
And what we can see
on the--the bottom left
is where the content
that I enter
through the admin interface
will appear,
and it says
that's where it'll be,
and on the right
we've got gadgets.
So gadgets are things
like open--
OpenSocial gadgets,
which you may know from places
like iGoogle, Orkut,
or our Apps Marketplace.
We also have widgets,
which are using our ability
for third party, um, companies
to integrate with Blogger
using the Blogger XML templating
language I showed you before.
Another advantage--
and, well,
who here has had
that wonderful call--
you're deep into figuring out
a deep technical problem,
you've been working on it
for like an hour,
you've got it all loaded
into your head,
and your client rings you up
and goes,
"I'd really like
the line at the top
to be in a different color,
and, you know, a bit bigger,"
and you're just
sitting there going,
"I really could have not done
with this phone call,
because I just lost
what I was thinking about"?
Well, we've got a wonderful
template editor,
a template designer,
which you can then
train your customer
into how to make things
different colors.
What I'm showing here
is changing my heading font
to use the Google Fonts API
impact font.
So you can have
your customers come to you
with these wonderful problems,
and you can go,
"Here you go.
You can do it yourself."
saving you from losing
all that context,
so you can actually
get some coding done.
Okay.
Time to look
at approach number two.
There's a couple of ways
to use JavaScript with Blogger.
First one, obviously,
is putting JavaScript
in the template
you were crafting
back in step one.
The other way is we can render
a completely new user interface
using just HTML
and JavaScript and CSS,
and pulling the data
from the data store
using JavaScript.
Okay, I'd like to show you
some examples
of--of this sort of technique.
What you can see here is that
it's dynamically loading,
and,
boy, your machine's slow, Bro.
We've got this--
this ability
to dive into things,
maybe--yes.
I love demoing things live.
What we're looking at here
is the ability
to have a blog,
or any web site
that isn't the traditional
main line of content
with a sidebar.
We've got navigability.
We've got the ability
to dive into things.
Scroll down,
and--that's right,
we've got a few tabs open.
And here is exactly
the same content.
Nothing's changed
on the back end.
Totally different
look and feel.
What I'm actually
showing off here
is a feature that Blogger
released fairly recently
called Dynamic Views.
But there's nothing
actually stopping you guys
from doing this,
and we'll get to that
in a second.
Oops.
I should probably go back
to the presentation.
Did I just close
the presentation?
No.
Okay,
part number three--
using RESTful APIs
with Blogger.
And here's where we get
to announce something--
well, actually,
announcing a preview.
What we're doing
is we're releasing
a new API
in the coming short term...
um, that will allow you
to pull in all the content
that we were seeing before
using JavaScript, um,
and we'll have,
as you've probably seen
in the other API talks
we've had on this track,
we've got client libraries
for Java, PHP, python.net,
and I'm missing one--Ruby.
So you'll be able to grab
all the content
that your users have put in
using the admin interface,
pull it out,
and re-render it
in various different ways.
So what can you do with this--
what parts of Blogger
can you get to?
Well, you can get
the--the blog information,
the actual posts, either
in a list or individual format,
comments, and the static pages.
Static pages are usually
used for things like,
uh, "about us,"
"contact us," "FAQs."
This means that not only
can you have your clients
entering, say,
constantly changing information,
as blog posts,
but you can also give them
the ability to edit content
that would be so linked
from the--
the top right of the page--
the--the--the stuff
that's always,
uh, relevant.
This means that you can give
the ability to your, um,
your clients to change the look
and feel of their site
without needing
to bother you constantly.
So let's actually have a look
at the APIs that we're giving.
Firstly notice it's on HTTPs.
All of the new APIs
that Google are doing
are all over HTTPs.
They're all also based on
googleapis.com.
The part that's different
is Blogger v2 blogs
and underneath.
So this one is pulling back
a specific blog.
So first line, "kind,"
is constant--is in all
of the data we're returning,
tells you what
you're looking at.
This means you can write
some generic code
to pull this into whichever
format you prefer
and basically switch off that.
The next line is the primary key
of the object you're looking at.
The next one is,
in this example,
would be the blog title,
and the next, the description
would be effectively used
as a subtitle.
Then we've got "created"
and "updated"
as time since Epoch,
uh, the link where it's actually
hosted on BlogSpot,
so on and so forth.
Now under a specific blog,
we can get all the posts
in a paginated fashion.
There are a list of them,
[speaking indistinctly]
because we can also get them
individually,
and it's using
exactly the same format.
So again we've got "kind,"
then we've got the primary I.D.
of this post
and the blog
that it's related to,
and then we've got the name,
which is the post title,
and the actual content,
which is the HTML
that you've entered
through our admin interface.
And then we've got the author
who created it.
Useful for things
like bylines.
Now we've also got comments,
available as a list,
again, same format.
So here we've got "kind,"
Blogger comment,
we've got the primary key
of the comment,
the post that it's related to
and the blog
and what was actually said.
And now static content,
again, as a list,
as individual pages.
So now that I've walked
you through three ways
of integrating with Blogger,
it's probably time for
that live coding exercise,
where Pat shows us
how it is done.
Coleman: Thanks, Brett.
Okay, so now Brett's
walked us through
what sort of resources
we give you access to
in this new updated Blogger API,
um, so what
I will be doing
is taking sort of a scenario
where we want to build, like,
a small web site for a business,
and we're storing their data
inside Blogger,
and then using these APIs--
one for each resource--
to grab that information
back out
and display it in a web client.
Um, now just briefly,
for this demo
I'll be using GWT.
Uh, for those who aren't
too familiar with it
or haven't used it before,
um, how this works is
I'll be writing Java code,
which then gets compiled
into JavaScript,
and then can be served up
from a static HTML page,
um, with CSS or whatever
you like applied to it.
So the nice thing about this
is you could easily, say,
once you finished it,
[speaking indistinctly]
within a day,
and the overhead of actually
serving up that HTML
and JavaScript content
is really, really low.
And the way it will be
structured in this case
is for every resource--
uh, Brett's already
walked you through
what the model looks like
for that resource,
so that's all the content
that's stored, um,
for each bit of information
that you get back.
What we then have
is a presenter,
so that's gonna be talking
to our API,
uh, making
the Asynchronous Fetches
of this model information
for the data we want,
and finally, the bit
that we're really interested in
is the views, so how this, uh,
common model information
can be presented
inside a JavaScript client.
Okay, so imagine this--
you've got a business
that's come to you,
and they want a web presence.
But, say, they've spent money
on advertising,
or maybe they want
to lower their overheads
or even, um, cut the costs
of all the products they've got,
so you want to base it
on a way that's
easy to update,
but also low overhead
of maintenance of the site.
And for this instance, uh,
we're using Blogger to say,
uh, the business
that we're running
could be one where
you've got products overall,
so each post that they make
matched to a product
and vice versa.
And then, uh,
for this example,
say you've got a product
that you have that
is a special for a week,
so the most recent post
is the most recent product,
and that's on special
for this week,
and you want to grab that
information and display it.
But then, uh, it might
also be useful for customers
to, on their site,
go back over the list of posts
and examine what previous
content you've got,
or previous products
you've been selling,
and maybe even what users have
said about their experience
either buying with you
or using your products.
So let's see if this works.
Sorry, my thing was down
last time I checked it.
So fingers crossed.
Um...
This should eventually load
as the blog
where we're storing the data.
And just in case,
I'll try and load it
from a different area.
Okay, and what
we will see here
is just a normal
Blogger looking blog.
There we go.
So as I said,
imagine we've got--
we've got a business
which is running their products
through their blog,
and in this case,
uh, just for this example,
we've got a business
who are selling vases.
What they do is
for each product they create,
um, they--
one of their authors,
or one of the people
in the business
can go into
the Blogger admin API,
create that post, hit publish,
and it will appear on this blog.
As you can see,
they've got a name.
They've got a little
description,
but it's not really--
it might not be stylized
to what their product--
uh, what their company
wants to look like.
So it doesn't have
their logo yet.
We haven't customized
the template
any further than the original.
Okay, so what we want to do
is now set up this client,
uh, in GWT to grab this content
and render it how we like.
So what I'll do
is I'll switch over
to, uh, the GWT client.
Make sure it's running.
And what I've started off with
is a really basic page.
It's just all the overhead
that you need to,
once the page loads,
start executing the JavaScript
that you're coding up
in your client.
So for now, we've got
[speaking indistinctly]
but later we'll end up
talking to the API
and populating this data.
Right, so the first resource
that Brett was talking about
was his blog resource.
Uh, the model is exactly
as shown before,
so you've got the I.D.
You've got the name in HTML.
Um, we support HTML
on descriptions as well,
and you've got things like
post count, which, in this case,
could be used to say
how many products you've got.
Um, you've got
when it's updated,
in case you want to, say,
cache the results
and not have to talk
to the API all the time.
And then to get
this information,
we go to that base HTTPs
googleapis.com/blogger/v2
for this version
of our API,
and then at the end of that,
we add /blogs,
and then the blog I.D.
of the blog that we're using
to host all of our data.
So that's the URL
we get this information from.
Finally, the view that we're
gonna use in this case,
or, uh, in--we might just like
a splash landing page.
So you'll have the logo
of your business added.
Um, you can also have
the name stylized
and the description stylized,
so we'll use those as our
initial page for the view.
Okay, switching back
to the client itself.
Uh, I'll open up the view
in the GWT code that--
I will be skipping
over these, mostly.
Um, it's sort of--
the views are defined by
this templating language,
which looks like HTML,
but gives you--
and can be styled like HTML.
It can have HTML elements
inside it,
but it also lets you
point out certain elements
in your HTML
where information will go.
So it's not the easiest
to understand,
but for here, we've got,
like, the splash page.
We've got a section of HTML
for our name,
section of HTML
for our description,
and an image for our logo.
Um, what might be so easy
is switching to the Java,
which compiles
down to JavaScript,
which then forms that view
in our client.
So what we do
when we've got a blog,
we take that model,
we find the information
that we are interested in--
in this case,
it's the HTML of the name
and the HTML
of the description--
and then we find the areas
in the HTML
that we want to add that--
those labels to
and just set them outright.
So what I will do is
once we make the API call,
the model resource
will come back,
and then we'll build the HTML
on the client.
Okay, so finally,
to get this all running,
um, I probably should remove
the windowed alert
and instead replace that with--
once the client loads,
we add that overall view
to the root of our HTML.
So their whole page
will be filled
with this initial
landing page.
So I'll kick off a compile.
And just to remember, um,
all of this is run
in JavaScript,
apart from the initial,
like, serving of the HTML.
So what will happen is
we'll get a skeleton of a page
loaded up first,
and then the API fetch
will go and talk
to the Blogger APIs.
Um, it will do that through, uh,
in the GWT library that does
JSON PECLs for you.
And then once that result
comes back,
we'll fill out the parts
of the HTML
with the information
that we want from our model.
Okay.
So we'll run this.
Now when I hit refresh,
you see the image loads,
'cause that's part
of the framework.
Uh, you get the page
at the top,
and then once the information
comes back,
you get the name
of the company--
um, here we've just added
a bit of web font styling--
and then the byline.
So that's the information
from a blog,
but, say you've got
regular customers,
they'll probably know your logo
and your name already,
and this content might not
change very much,
so what we really want
to get in there
is the product information
for everything that you have.
So instead of doing it
based off blog information,
we now switch to using our model
as being the posts.
As before, you've got
the post model,
which is the--the I.D.
of the post,
um, the name--
so that's the HTML
that the post is titled.
Uh, you've got the HTML
content of the post
direct from the Blogger
back ends.
You've also got this nice thing,
which is the author,
which applies to anything
which is authored
inside the Blogger API,
so it gives you the name,
their profile picture,
if they have one,
their link to their profile,
um, and then the number
of comments on the post.
So we do it this way
just because
the comments themselves
have different resources,
so rather than serving
them up with, like,
a large overhead on the posts,
we give you the number
of comments,
and it's possible to form
the URL to fetch those later.
But the URL for the posts
is exactly as before,
so because the post was
[speaking indistinctly]
in a blog, the start of the post
URL is the same.
You've got the Google APIs
and then Blogger v2,
uh, then followed by
/blog/blog ID
for the blog
that the posts live in.
And then finally, we want
to get one particular post
of the product
which is special this week.
So there we add /posts
and then /post ID
for the I.D. of that post.
We make that call, get back
the information from the APIs,
and now we need a way
to display this to the user.
And just as before,
we set up the HTML template
with areas for where the name
of the pa--uh, post goes.
Same with here,
where you can add an area where
the name of the author goes,
in case, like, uh,
different authors might publish
different types of product.
And then finally,
we have an area
where the HTML
of each post goes,
so that will be information
about the product,
the pricing, how to buy it,
um, all that information.
As with before,
we create a view
to display our posts...
and in this case,
we render the post
similar to how we
rendered the blog.
We find where on the HTML page
the post name goes.
We format the name to say--
in this case,
we can link it
to the original blog post,
and then we push that
into the page.
Same with the, uh,
the content of the post,
and we just grab that
straight from the model,
and similarly,
we now grab the author,
and we get their name
and put that
where we want on the HTML.
Uh, finally,
in our overall view,
how we'll display this page is
rather than having
a splash landing
with the one tab at the top,
we're gonna add a second tab,
which is this week's,
uh, special,
uh, product.
And so now we've got
a second tab for that.
Um, as before--I'll just
kick off this compile.
Uh, that's all right,
I just have to,
once we grab that information,
push it into the view,
so that it updates
once the fetch comes back.
Okay, so once we run this,
it will have the same initial
load as before,
so that HTML framework
of the page,
but with new information.
Um, it will then do the call
to get the blog's name
and the blog's description
and put that into
the splash landing page.
And then simultaneously,
it will grab
the most recent posts
information
and put that, uh, invisibly,
into the second tab on the page.
So here we go.
We'll serve our client locally.
I'll go to this.
Refresh it.
You get the same
frame as before,
but you can see
there's now, uh--
not too easily on this screen--
but there is a second tab
at the top left here,
um, with the special.
So once you click on it,
you get today's special,
which, uh, is grabbed
straight from
the blog post HTML.
We can style this however
we like on the client,
so if your authors have gone in
and not applied any stylings,
then this--
the HTML that they published,
will get whatever styling
is from its parent.
So say our business had
a particular font they liked,
any post could be rendered
in that font here.
Similarly, you can add
information
around the outside
of this post.
So here we've added, like,
a "buy now" button,
so that would then contact,
in this case,
our Google Checkout account,
um, the user--the customer would
then go be able
to send us a purchase request,
and we could process that, uh,
with however way we've got
set up for our company.
Okay, now a third type
of resource
that Brett was mentioning
was these lists of posts.
So in the new Google
infrastructure for APIs,
the lists work nicely in that
they sort of just wrap
the existing resources.
So here our list of posts
is just a list
of these post models
that we've already--
know how to load.
We already have defined
a view for.
So what we're doing
for this section
is, uh, the model
is effectively the same,
the API call,
instead of
to a single I.D. Post,
now we're doing it
to the entire collection,
um, which we can paginate
if we--however we like.
And so we do /posts,
and that gives us, uh,
quite literally,
just a list of these
post objects.
And--sorry--as we expand
on this,
we'll be able to add
query parameters.
So you could say give me all
posts that have a certain label,
so maybe it's
"half-price" label,
or, uh, "blue vase" label,
or whatever labels you're adding
to help you categorize
your products.
You'll be able
to grab that category
out of your
product information.
And then the nice thing
with the same model
is that we can reuse
the same view.
Uh, in this case,
we will have the product
and then sort of navigation,
so you can sort of
traverse through time
to go--to delve
into past products.
Now the code for this
is very similar to before.
So we've reused the views.
Um, we've got a--
uh, one view for doing
the list of posts,
but really that's just comprised
of this single post view
and navigation, um,
plus some events,
so you can click left or right
to go back and forwards.
Um, how we display this
on the main page
is similar to how
we did before.
Uh, rather than adding a tab
to get the most recent deal,
we can add a tab to get
the list of previous deals.
And then once that API call
comes back,
we take that list,
uh, push it into the HTML,
and then it will get rendered,
uh, whenever
the fetch comes back.
Okay, so the difference here
is the initial landing page
will look the same,
but there will be a third tab,
which you probably, again,
won't be able to see
under this black screen.
Um, but yeah,
so that information,
once we fetch it from the API,
will then be displayed
into our page,
uh, and be able to be viewed
one page at a time.
Okay, let's see if that
picked it up. Probably not yet.
Okay.
So looking at the new client.
Yep, you've got the same
introduction page as before,
um, you've got the same
single deal as before,
but now we've added, like,
a little stylized
reflection here.
You can navigate
through previous deals.
So these are the ones
that we've had.
And as you can see
from this page,
that's exactly the content
that's come from the blog.
Now one advantage
that you get from this
is that if your--
your clients,
or the people running
the business,
say, they're visiting
their own web site,
and they see maybe
they had a--
there's a spelling incorrect
in one of the products,
or maybe the price
that it's been offered at,
they want to adjust it slightly
'cause, say,
it's really popular,
what they can do is go to
our Blogger editing--
uh, publishing U.I.,
so long as they've been added
as an author
or an admin of the blog,
they can then go and correct
out the content their selves,
in either, uh,
HTML editing mode
or in our WYSIWYG, uh,
NicEdit editing experience.
Plus, as we're pushing out
new features to this new U.I.,
so, for instance, now we're
making it look slightly nicer,
act faster,
we could be adding
features to our editor--
that entire publishing
experience
will be improved
for your clients,
So they can add links.
They could add videos,
um, even custom JavaScript
inside each product.
Um, they could have
an original template
which each product
is based off,
and so they could then
pull in the image,
uh, pull in
the short description,
and then it would only take,
say, a few minutes
to get one of these product
pages up and running.
Okay, the final resource
that we haven't covered yet
that I'll be using
in this demo
is displaying feedback about
each of your products.
So the resource
we're using here
is the collection
of comments,
which, as before, is just a list
of these comment model objects.
So that includes, like,
which products they are on,
um, which blog they are on,
which would be the same
in this case,
uh, their HTML content,
and the person who wrote it.
So we do support
anonymous commenting,
so it might not
always be there,
if the comment
was made anonymously,
but for most users,
you'll get, like, their name,
a profile picture
if they have one,
and things that let you display
the comment in a nice way.
Uh, finally, to display it,
we'll just add a section
down at the bottom of each post.
So because the comment data
isn't available at first,
we'll sort of start this out,
uh, collapsed,
if there are comments
on the post,
and then once it's expanded,
we can basically go off,
do that call.
Once that data comes back,
we can fill out all the comments
that have been made
on that product.
Okay, so translating this
into the code.
Uh, for each post,
we want to enable
this little comment section
down at the bottom.
That's what this, uh,
bit of the template
that I'm uncovering there is--
it's the section that will
expand out once you click on it.
Hooking them up--
that up to the post itself,
uh, firstly, we need to add
a bit of event logic
to handle making the API call
once you, uh, expand it out.
But once that's done,
we'll get just a simple list
of this comment
model object back
and push that into the HTML
one after another.
And for those who are curious,
this is exactly what
our comment model looks like.
So, uh, because the way that
GWT is written in Java,
uh, you sort of need accesses
into this JavaScript
that's returned,
'cause you can't easily, uh,
use it just as JavaScript.
Um, but in this case,
we have small wrappers
that go across
each of the attributes,
so for our content
in our comment,
we just have this "get content"
model--or, method.
The one other nice thing
about this
is for those who saw
the talk earlier today,
um, part of the common
APIs infrastructure
that we are launching
this API on
is a discovery document,
which tells you
for each resource you have
exactly what these properties
will be.
So you can think, for each
of our model objects--
so here I've got like
blog, comment, post--
all of that code can be
automatically generated for you.
You don't even have to worry
about any of that,
and it will give you typed
access to all of the values
that you're pulling back
from the blog.
Okay, so once we've got
this comment data,
um, we make no change
to the overall view,
because if you remember,
this is only being added
to the--each post,
um, and so the initial view--
the initial load
will look very similar.
You'll get the blog information,
the blog description,
and because of the way
that we set it up here,
uh, any post that doesn't--
or any product that doesn't
have any comments
won't have that section
down at the bottom,
but for the ones that we do,
you'll get this new, uh,
expandable div.
Okay, so I switch
back to our client.
You get the same
initial page.
Uh, you get today's special.
And as you can see, just--
now it does have comments.
We'll navigate
to this area,
and for whichever pages
have comments--
remember, the comment data
hasn't loaded yet,
so even if it had
50 comments,
that wouldn't have slowed down
our initial page load.
But once we click it,
we'll go off to the API call
to blog--Blogger API--sorry,
googleapis.com/blogger/v2,
and then /blog/blog ID,
/post/post ID,
and now /comments.
Grab that information--
that comment data back,
and then use it
to fill out this HTML.
So we expand it,
we get the comment,
and there you go.
There's the comment data.
Um, you can even add caching,
so that every time you load it,
uh, the comments
are still there.
And this is the same
for any post.
So now we go off.
There's that comment data.
And we can navigate through.
So there you have it.
It's like a small GWT app
that you can use
to display, uh, for the use case
of having a business
which has, like,
a list of products
and one that's on special,
but you can imagine taking this
and applying it to whatever
blog you are interested in.
So you could--if you had, uh,
tolls for the views
that you have,
you could easily run, say,
three different business blogs.
Or in the case
of the dynamic views,
um, if you make it
general enough,
you can, in fact,
apply that client view
to whatever blog
you're interested in.
So if I change the blog I.D.
that this is pointing at,
um, to, say,
my own personal blog,
I'd be able to read my blog
in that format instead.
Now as Brett said,
we haven't, uh,
launched this API
on the googleapis.com
site yet.
Uh, the interesting thing
about today
was opening a discussion
to see what sort of information
people would like on, uh,
attached to each resource.
So we have blogs.
We have posts and pages
for the more static content,
um, plus comments,
but we're still solidifying down
what information
will be available.
And similarly, for now,
we're concentrating more
on, like, a read-only API,
so as you have seen,
we're fetching
information from Blogger,
um, and--
but we don't yet
have exposed ways
to put content back in.
Uh, but that's more of a matter
of we're hoping the solidify
the model objects first
to really see
what sort of visualizations
people want,
whether it be for a business
or for an overall blog.
And then once that's settled,
we can see at ways to be able
to publish that new content
from whatever visualization
you like.
So you can imagine setting up,
uh, your business
publishing page,
where you've got maybe
four forms--
uh, I'm sorry--
a form with, say, four fields
like image, uh,
medium description,
price, uh, longer description.
You hit a button,
publish that information
to the Blogger API.
That will get added
to the overall blog,
which has the--
say you have customers
that use RSS readers,
or use our new e-mail
subscription
to the blog feature,
they will get that information
as soon as it's posted.
But then additionally,
if you have
one of these clients,
you'll get that information
as soon as it's there.
Um, and so, say,
we had a new post--
once you load today's special,
that will grab the most recent
post from the blog,
so you don't
have to worry about
updating your overall
business web site.
Okay, that's it from this demo.
I'll throw you back over
to Brett to close out.
Morgan: Okay.
[speaking indistinctly]
Okay, so what did we
show you today?
First off, I talked you through
why you should use Blogger.
Then we looked at three ways
of using Blogger,
including our new upcoming API,
which we'll be getting out there
really soon now,
and finally, we had
a live coding exercise.
Um, if you've got some feedback,
or you're twittering about us,
please use those hash tags
so we can all follow along,
and I'd really love it if you'd
give me feedback at that URL.
But it's now time for Q & A,
so there's a couple of ways
you can get hold of me.
There's my e-mail address,
brettmorgan@google.com.
Second part--
I'm on Twitter, oh, my God,
and finally, there's
a Google group that I run
for people developing
on top of Blogger.
But we've got some
microphones in the room,
so questions, please?
man: Hi. Thanks for
the presentation.
Um, uh, this new API,
does this, uh,
is this an additional API,
or does it replace the old one?
'Cause, uh, I've been using
this whole kind of model
for a couple of years now,
I think.
Um, so what does that--
what happens to the old--
I think it's been a while
since, uh,
I believe it's Google data...
Morgan: The Google data APIs.
man: And, um, what else?
Uh, it's ATOM or RSS,
pretty much...
Morgan: yep.
man: if I remember right.
So I'm assuming that this
will have every...
Morgan: Okay, so what's
happening here is
Google data APIs
are the solid--everyone
knows how to use them.
We've got them well tuned.
They're--
they're in their platform.
This is effectively
our experimental area,
where we're looking at--
Google data is all XML.
It's kind of heavy.
It's kind of--
it's kind of nasty to use from
JavaScript in a web browser.
What we're trying to do here
with all these data models
and JSON
is allow people to experiment,
play on the web browser
or on the android phone
or so on and so forth,
be able to deal with their APIs
in a light way
that's, you know,
buzzword compliant,
um, and talk with us and go,
"Okay, I've got this wonderful
new use case.
How can you help me
make it a reality?"
so that's the discussion
we're looking to have here.
man: okay, so it doesn't really
replace that whole thing?
Morgan: No.
Coleman: You'll still
be able to use that.
Um, but as Brett was saying,
this is like
a very lightweight approach.
man: Yes.
Coleman: So we do encourage
people to use this new system,
especially as it will gain
any advantages
that are written into
the overall APIs infrastructure.
So, like, all the server
side libraries
that are written for you, um,
you'll be able to use them all
with this new API.
Morgan: Yep.
man: Thank you.
Morgan: So basically
to cover it back,
the new API structure
is a Google-wide thing.
We have got new API libraries
coming out,
client libraries coming out,
so on and so forth.
So if you're developing
something new--yeah.
man: Um, two questions...
Morgan: yes.
man: Where do you want
the feedback for the API?
Not for the presentation--
Morgan: Oh, for the API,
you can either talk
with me directly,
or take one of those
three methods.
Probably the bottom one's
a really good one,
'cause that way
you can have a discussion
with the other users who are
also developing atop Blogger.
Coleman: Mm-hmm.
man: Um, and conceptually,
I've done client work before,
and a lot of clients
like to think of having
a CMS to manage their content...
Morgan: Yeah.
man: is that the kind
of paradigm here?
Is that what you're thinking?
Morgan: Blogger is a CMS.
man: Right.
Morgan: It's a very light one,
but, yes, it is a CMS.
man: So is it--
is there any way to, um,
to--to structure the content
in the CMS, um,
beyond what a blog post is?
You know, you've got your title,
your content, your comments.
Morgan: At this point, no.
man: All right.
Okay, thanks.
Good presentation.
Morgan: Thank you, Jonah.
Any other questions?
Or are we all
rushing to the bar?
I think we're done.
Thank you very much.
Coleman: Thank you.
