Recently in Web Development Category
I used the drivers here: Precompiled JDBC SQLite drivers
The source is here, though it may not be the same: Source
I dropped the Linux JDBC and .so files into [cfmx7root]/lib/ and restarted ColdFusion. Then I created a database using SQLiteQuery on my Mac and added a table, column and single value. Then I copied the db file to a test folder on my server and just ran a select * from table.
My datasource setting is as follows:
JDBC URL: jdbc:sqlite:\var\www\html\sqlite_test\cfmltest Driver Class: org.sqlite.JDBC Driver Name: sqlitejdbc.jarAt that point, running the code threw an error that the table didn't exist. Permissions were all okay, so I executed a CREATE TABLE via the .cfm file with a different name, column and value. That table showed up. Turns out that the table I created on the Mac only shows up on the Mac via the GUI tool, and the table I created via CF only shows up for CF, even if I query the master table to get a table listing.
I'm thinking that has to be something to do with driver versions. If I get a chance to test further, I'll run some speed tests versus reading and writing files, XML, etc. to see what the speed is like. This is also obviously insecure, you don't want your db file to be readable by the web server.
UPDATE: now that CF8 includes the Derby java database, this is somewhat moot. Though it does give a way to interact with existing sqlite databases. I still don't know why some tables don't show up, again probably a version/driver issue.
www.work.psu.edu has a new interface, and I really like it. As I was checking it out today, I thought about the fact that we don't seem to encourage each other much within ITS. I don't know who exactly worked on the new site, and it's probably a case in point that I don't, but here's a big thumbs up to you.
There are many large, complex systems behind that pretty new face, and I keep thinking about how much of what we do in ITS gets lost because we don't seem to have a good handle on the face of data. Google and Apple don't discover fire, then invent Zippos. Somebody has to discover fire, and keep it burning, but when you cook something with it you'll capture your audience.
That was a really belabored metaphor for a simple idea that I'm trying to express. We need to get better at exposing the really cool stuff that we do to the "average" users in our extended community. Architects and engineers really need to start to understand HCI and interface design, even if they never actually build an interface. I'm sure that's not a popular sentiment, but there it is.
Jimmy V. has a couple of posts on his blog that I really want to comment on. First, I like Jim. We were in ITLP together and I respect his experience in software development. He does good work.
Second, I agree with many of his points. I've worked on more than a few web applications that brought interface and design experts in too late or not at all and ended up being unused and/or harshly criticized even though the application logic and data model were very well done. I've also seen web apps that had good designers who were asked to put lipstick on a pig.
Having said that, Jim and I are very different in our philosophies. I build web applications, though I really don't like HTML. I build databases, business models and application logic, though I do dabble in interface design on occasion. I really believe that web applications, and the types of applications that they're evolving into, are going to dominate ITS development for the foreseeable future. Furthermore, those applications are being built in dynamic languages that are interpreted rather than compiled. That's why the model presented in this article is much, much closer to the way I work. Most of the coders, designers and architects that I talk to and work with work this way too. In fact, I doubt that I could code without knowing what problems I'm solving and seeing the bigger picture.
The web has issues, but the paradigm of rapidly developed (and rapidly replaced) data-driven, networked applications is here to stay. It seems that so much of the discussion in ITS over the last couple of years has been about meeting student and faculty needs and anticipating demand. I think I can sum that up for you - any information I want, any time I want it, on any device I choose to use. I'm loving that challenge.
The new Penn State Undergraduate Bulletin Online is going live, the previous site is slowly being phased out as links are changed to the new URL.
The site is built on ColdFusion 8, Red Hat Linux AS 4 and MySQL 5. I built the database and wrote the application logic, while the design and standards compliance was handled by Web and Media Design Solutions. The course data comes from the University Course Master, while the majors and other degree programs are HTML files with metadata in the db. I built a very simple CMS to allow the text stewards to maintain the programs and general information sections.
We've already had requests to integrate with other projects in ITS and share data with groups like the Registrar and Commonwealth Campuses. I think this is an excellent opportunity to model new ways of collaborating and especially exposing information in the University's enterprise infrastructure to the web and other channels. I think that we will start to see quite a few new projects in a similar vein in the coming months, as more departments and groups look for ways to share information and meet student needs (and demands).
I worked with quite a few talented and dedicated people on this project, including the sysadmins in my own group, Web and Media Design, AIS and Undergraduate Education. People like these make Penn State a great place to work.
I design and build web applications, databases and business models. Sometimes clients will ask me to incorporate a dynamic doodad or auto-loading widget, usually to facilitate form completion or make it easier to drill down through large record sets. There is an interesting disconnect between sites I build that are public facing, and sites that are exclusively or primarily for use on PSU networks and systems. The public sites almost always incorporate some AJAX or Flash while the internal sites almost never do. This is because on the few internal sites I have built with some javascript we have received complaints about broken functionality. Cookies also seem to be banned in many areas inside PSU.
Now, I understand that some groups and departments really do need to lock down everything. I have to wonder though, how many areas disable JS, cookies, flash and other client-side content without any clear reason other than a vague idea that they're "not secure"? The new Web Bulletin will have almost no javascript, certainly none that will break the site if it's disabled. The Bookstore's Online Textbook Adoption System has some that I added after the fact, and we're looking at adding more to facilitate navigation and selection of books and classes. Even the small amount we have now though has generated error reports from groups where JS is disabled. As I'm developing the new Computer Store catalog, I'm struggling with how much Web 2.0 functionality to add. Perhaps this is something else to bring up with ITANA.
Recent Comments