Davida's Blog

Well after tomorrow, class is basically over with. Where did the semester go?

Lori typed a blog entry about fixing some errors and we are kind of lost about our error page because the api isn't working. Does anybody have any last minute ideas? I was going to suggest maybe a pop-up-window, but I don't know if will work. Please help us out!

Chapter 6 Summary

• XML, the extensible markup language, lets you structure your data using elements and attributes.
• XML allows a server’s response to include more than one piece of information, without requiring proprietary data formats or special formatting.
• You can get the DOM representation of an XML document returned by a server-side component using the requestXML property of the request object.
• When the browser receives an XML response from a server, it creates a DOM tree representing the document.
• Creating XML manually, using plain text, is error-prone and usually requires a lot of effort.

Chapter 5 Summary

• In a GET request, all the data you send to the server is added to the request URL.
• Each browser has a maximum length for URLs, including any data included as part of that URL. For most browsers, that maximum length is around 2,000 characters.
• There isn’t a length restriction on the data you send to the server if you are using a POST request.
• In POST requests, the data is sent to the server separate from the request URL. The request URL only has the name of the program on the server that should be run.
• You can send different types of data in a POST request: plain text, XML, binary objects like images and files, and anything else that your web browser can encode.
• The server doesn’t know what type of POST data to expect unless you tell it.
• Using the Content-Type request header, you can tell the server what kind of data you’re sending in a POST request.
• POST requests are only marginally more secure than GET requests, and both require additional layers of security – like SSL, the secure sockets layer – to protect your data from prying eyes and malicious programmers.

I'm having an issue with rebuilding my  previous entry. It shows up when you login to learning remix, but if you click on the link to my particular blog, the entry doesn't show up.

Has this happened to anyone else?

~Edit~

This is the error message I'm getting:

Building date-based archive 'Monthly20061201000000' failed: Build error in template 'Date-Based Archive': Error in <MTEntries> tag: Error in <MTIfPingsActive> tag:

Prof Gibson talks about XBRL alot in class, especially when focusing on the group WebFinancial. I'm sure that someone else besides me doesn't know exactly what he's talking about, so here's a little information about it.

XBRL (eXtensible Business Reporting Language) is an emerging XML-based standard to define and exchange business and financial performance information. The standard is governed by a not-for-profit international consortium (XBRL International Incorporated) WWW.XBRL.ORG of approximately 450 organizations, including regulators, government agencies, infomediaries and software vendors.

XBRL consists of an instance document, containing primarily the business facts being reported, and a collection of taxonomies, which define metadata about these facts, such as what the facts mean and how they relate to one another. XBRL uses XML schema, XLink, and XPointer standards.

XBRL is a standards-based way to communicate business and financial performance data. These communications are defined by metadata set out in taxonomies. Taxonomies capture the definition of individual reporting elements as well as the relationships between elements within a taxonomy and in other taxonomies.

Taxonomies are a collection of XML schema documents and XML documents called linkbases by virtue of their use of XLink. The schema must ultimately extend the XBRL instance schema document and typically extend other published XBRL schemas on the xbrl.org website.

As we all know Prof. Gibson gave his IS 215 class a chance to review our projects. I must admit that they were a little brutal, but I just laughed at it. Like I told Lori in response to her entry about the reviews, these students don't have a clue how hard and time-consuming this project is, but let it be known, they will definitely find out. Karma is a (fill in the blank)!

But anyways, I have summarized the reviews into three categories: Good reviews, Bad reviews, and Suggestions. They are as follows:

  Good Reviews

• It’s easy to use.(3)
• It is very useful.
• Quick and efficient for hotel searching.(everyone)
• Simple and easy to understand.
• Formatted nicely.
• Appears professional.
• Nice idea.(6)
• Very convenient.
• Step-by-step directions made it easy to use.
• Blunt and to the point.

Bad Reviews

• It looks horrible all together.
• It looks like no effort was put into it.(2)
• Layout is not catching to the eye.
• Bad site all together.
• No title for the website.
• Small font, made it hard to see.(2)
• Site doesn’t work.(6)
• It is a waste of a perfectly good URL address.
• If it doesn’t work, then there’s no use for it.
• Gray background is very unattractive.

  Suggestions

• Make the font bigger and change the background colors.
• Add an indicator that lets you know you spelled something wrong.

If they could only see our website now, lol!

I think yesterday's class went very well. I think that everyone's project is coming along. I was surprised that we showed the new and improved kayakers site for our weekly update. I thought that we would've saved that for iteration 3, for all the ooooh's and ahhh's at the end, or as the saying goes, "save the best for last." At least that's what I would've done.

But it looks really great! I told Lori that over and over again yesterday when she sent it to me in an email. We just got to fix some errors in which I don't think it will be a problem for us. We sat and talked and said who's doing what, so by Monday, we should be fine. I just pray that our website works, because obviously we learned last night, that it has a mind of its own now. So keep your fingers crossed.

The GET Method

The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI. If the Request-URI refers to a data-producing process, it is the produced data which shall be returned as the entity in the response and not the source text of the process, unless that text happens to be the output of the process.

The semantics of the GET method change to a "conditional GET" if the request message includes an If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, or If-Range header field. A conditional GET method requests that the entity be transferred only under the circumstances described by the conditional header field(s). The conditional GET method is intended to reduce unnecessary network usage by allowing cached entities to be refreshed without requiring multiple requests or transferring data already held by the client.

The semantics of the GET method change to a "partial GET" if the request message includes a Range header field. The partial GET method is intended to reduce unnecessary network usage by allowing partially-retrieved entities to be completed without transferring data already held by the client.

The POST Method

The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line. POST is designed to allow a uniform method to cover the following functions:

• Annotation of existing resources
• Posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles
• Providing a block of data, such as the result of submitting a form, to a data-handling process
• Extending a database through an append operation

The actual function performed by the POST method is determined by the server and is usually dependent on the Request-URI. The posted entity is subordinate to that URI in the same way that a file is subordinate to a directory containing it, a news article is subordinate to a newsgroup to which it is posted, or a record is subordinate to a database.

The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either 200 (OK) or 204 (No Content) is the appropriate response status, depending on whether or not the response includes an entity that describes the result.

If a resource has been created on the origin server, the response SHOULD be 201 (Created) and contain an entity which describes the status of the request and refers to the new resource, and a Location header.

Responses to this method are not cacheable, unless the response includes appropriate Cache-Control or Expires header fields. However, the 303 (See Other) response can be used to direct the user agent to retrieve a cacheable resource.

This information was provided here.

I've been done reading Chapters 4-4.5, but I just remembered that I always did a summary. So here's the summary for those chapters:

• Thr browser represents the HTML, CSS, and JavaScript that makes up a web page as a tree full of objects, using the Document Object Model (DOM).
• You can view and change the DOM using JavaScript code. Changes you make to the DOM are automatically reflected in the web page that the browser is displaying.
• You can use the JavaScript document object to access the browser's DOM tree for the current web page.
• You can use the DOM from any web application, not just asynchronous ones.
• A DOM tree is made up of different types of nodes: element nodes, attribute nodes, and text nodes.
• Element nodes can have only a single parent. If you change the element's parent, or add the element as the child of another node, you are moving the element in the DOM tree.
• You can add CSS styles and JavaScript event handlers to DOM nodes using JavaScript code.

If anyone still has the book, this is on page 274.