Archive for June, 2013

ExtJS 4.2 Walkthrough — Part 8: Logged In

Things have been going great. We’ve been plugging along in our app, making cool input forms and more or less getting to a place where we felt we had something that works. And then the bombshell.

One of the business users asked about the login form. Login form? Our impression up until this time was that this app was being developed for one person to use. And because we were going to keep this behind our internal network firewall, there really wasn’t any need for user authentication, session management, etc.

Well, so much for that assumption. Now not only do we have to provide some form of user authentication, the higher-ups also want to restrict access within the app itself to certain parts, so that only certain users can access certain sections.

We freeze for a moment, and feel that strange feeling of panic start to arise. But then we realize: oh yeah, we’ve been developing an ExtJS application. All of this will be easy, and will only require the most minor of refactoring.

Content in this thought, we return blissfully to dungeon raids in Cube World.

NOTE: The code for this session can be found on GitHub.

User Authentication and Roles

While the story above is probably a More >

ExtJS 4.2 Walkthrough — Part 7: Some Polish

In our last installment, we tackled the “Big Form”, the grand inventory management form that we’ve been working toward through our whole journey thus far. But even though it worked well enough, it was still incomplete, and we promised ourselves that we’d add in a few more features to polish it off, namely:

  • Add Car image management
  • Add restriction for Make/Model selections
  • Add “detail” view to the car.

Since we always live up to our promises (:)), it’s time we knock this out!

 

NOTE: The code for this session can be found on GitHub.

A Few Additions

Before we jump in headfirst, however, there are a few more supporting pieces we need to add. I’ll outline them below, and you can add them as you have a chance (it’s good practice, right?).

Drive Train Options

I created a new “Option” called “Drive Trains.” This should be managed under Options, and can have the same data structure as the other options. Eat, sleep, repeat.

New Car Fields

I added a few more fields to the Car model to make it more realistic to something that might actually exist:

  • VIN (string)
  • StockNumber (string)
  • Mileage (number)
  • Fuel (string)
  • Engine (string)
  • Transmission (string)
  • Drive Train (option/combobox)

After you add these to your database and ExtJS model, also add fields for these into the More >

ExtJS 4.2 Walkthrough — Part 6: The Big Form

After a few weeks off, we’re back to it! Hopefully, you’ve done your homework and are caught up 🙂

We’ve been working over the last several sessions on laying down some supporting pieces for some real functionality within our application. Not that we haven’t been doing “real” stuff to this point; but most of the pieces have been admittedly simple and are parts of the app that will be used infrequently. That is, managing car colors, categories, makes and models isn’t particularly “business logic”–they’re just ancillary (although necessary) parts of a greater whole.

But now that we have several of these foundational elements in place, we can really start plugging away at the core purpose of our app, which is Inventory Management.

So without further ado, let’s get to it.

NOTE: The code for this session can be found on GitHub.

Our Goals for this Session

In this installment, we want to tackle the following:

  • Build an Inventory Form for entering data
  • Wire up form to a new controller for adding/editing inventory records
  • Display inventory records in a grid (surprise, surprise!)
  • Build a search form for our inventory records

Our inventory management form is actually going to be a bit complex (not in difficulty, but in data collection), so we won’t actually finish the whole thing More >

My CBDW.2 Sessions

Wow, yesterday was awesome! My sessions went well (at least I think so), and I’ve received a lot of positive feedback from the discussions.

For everyone who attended, thanks very much for your participation…it definitely means a lot and I hope the sessions were as informative as they were fun to create.

If you didn’t get a chance to attend, the sessions recordings have been posted (see links below).

ColdBox Developers Week is not over, though–there are still a TON of great sessions through the remainder of the week, so be sure to check out the lineup and attend as many as you can. I promise you will not be disappointed!

Criteria Builder In Action Building CKEditor Plugins for ContentBox

 

Share this:

ColdBox Developers Week!

If you haven’t already (what, you haven’t? FOR SHAME!), be sure to register for ColdBox Developer Week, starting…well…today! This is a great week of really great sessions covering ColdBox, ContentBox, WireBox, AOP, ORM…phew!

Even if you don’t use ColdBox (yet…), I’d still encourage you to check out some of the sessions. It will give a you a good insight into what you’re missing out on 🙂

 

I’m particularly exited about this CBW, as I have the privilege of presenting two sessions!

Criteria Builder in Action (6.17.2013 – 11:00 AM Central)

With ColdBox’s CriteriaBuilder, you can build powerful and dynamic Hibernate criteria queries with very little code. But does it work in real life? To put that question to the test, we’ll explore some real life scenarios and see how CriteriaBuilder can help us

Building CKEditor Plugins for ContentBox (6.17.2013 – 3:00 PM Central)

In this session, we’ll learn how to extend CKEditor within ColdBox to provide rich, custom content editing capabilities. We’ll also explore how custom CKEditor plugins can be integrated with ColdBox modules to take content editing to the next level.

 

Hope to see you there!

Share this:

ExtJS 4.2 Walkthrough — Intermission…and Homework

If you’ve been following along the last couple weeks, we’ve been walking through the process of building a real(ish) application using ExtJS 4.2. We’ve made great progress, and we’re literally on the precipice of bringing together all the supporting pieces that we’ve been building thus far.

While I’m wrapping up the next installment, I have some homework for you 🙂 If you’ve been building your app in tandem with these walkthroughs, I’d encourage you to tackle the list I describe below. Not only will this put in place some pieces that are necessary for the next steps (and which I won’t necessarily cover in any detail), but will also give you a chance to try out some stuff on your own and get some very useful experience under your belt before we continue.

The Homework New CRUD Lists

The first thing to tackle is a few more of our favorite CRUD grids:

  • Make
  • Model

Both of these can have the same structure as the Color, Category, Feature, etc. tables. However, to make things a bit interesting, we’ll also want to create a foreign key on Model that will associate the relevant Make.

NOTE: As you’ll remember, our “option” editable grid is used by all our CRUD tables. it More >

ExtJS 4.2 Walkthrough — Part 5: Back to the Grind

After not one, but TWO diversions, we’re finally back on track! If you remember from our last installment, we built a handy editable grid with support for all our fancy CRUD actions. We also saw that we could build this in a very abstract way, thus accommodating a lot of separate but similar models, yet with very little code duplication.

While this approach definitely has its place, there are times when our data becomes a bit complex and no longer lends itself very well to the editable grid. In these cases, it’s probably best to go back to the ol’ web form…which is precisely what we’ll do.

 

NOTE: The code for this session can be found on GitHub

A Bit o’ Planning

Before we start hacking away at a form, let’s plan out what we’ll need. What we want to build in this installment is a management tool for Sales Staff. This has a few initial requirements:

  • Display sortable list of all Sales Staff
  • Allow for adding new Sales Staff members
  • Allow for editing existing Sales Staff members

And here is the data that management wants us to collect:

  • First Name
  • Last Name
  • Date of Birth
  • Address (Addy 1, Addy 2, City, State, Zip)
  • Phone
  • Hire Date
  • Position (a value from our “Position” table)

Now that we have our requirements, let’s More >