Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Alright, let me see if I can break this down into pieces and help you out.</p> <p><strong>Firstly</strong> It isn't clear the consistancy of your terminology, so I'm going to build a small glossary here so I am certain you understand what I mean:</p> <ul> <li><strong>Request Lifecycle</strong> The entirety of a HTTP Request through your application. Ajax calls are lifecycles, page loads are lifecycles, once the document is sent and the connection closed, the lifecycle ends.</li> <li><strong>Controller</strong> Code reponsible for controlling a <em>request lifecylce</em>'s execution through your website.</li> <li><strong>View</strong> The actual output <em>code</em> for any page/request. This is the code in <code>application/views</code>, and is used practically every time there is a <em>request lifecycle</em> (except perhaps redirects &amp; ajax).</li> <li><strong>Client Code</strong> The Javascript logic happening once the page is loaded. Ajax calls are made <em>by the client code</em>.</li> </ul> <p>I am going to answer your questions a little out of order, so bear with me:</p> <hr> <blockquote> <p>This brings forward my first, ridiculously simple, question. Is this okay? One of my main concerns is of course users who don't have javascript enabled; the application simply doesn't work. I have read about graceful degradation and progressive enhancement, but I'm just not sure if this application is do-able without JS.</p> </blockquote> <p>The <em>fact of the matter</em> is, Javascript is a pretty intrinsic part of what we call "Web Applications" now. The difference between a web application &amp; a web site is that the former is intelligent. Most <em>sites</em> usually just process requests and display the relevant data, <em>applications</em> however usually make decisions, update the state of the system and modify the output based on the input.</p> <p>What you appear to be building I would classify as a <em>web application</em>.</p> <p>I do not believe in this day and age of HTML5 (kinda) with the facebooks &amp; youtubes of today that it is unreasonable to require the use of javascript to use the web application.</p> <p>People who disable thier javascript these days do it through plugins like AdBlock &amp; NoScript which usually allow you to selectively disable things. The best way to combat this is to seperate your javascript into easily recognizable components so users will know <em>which scripts to allow.</em></p> <p><strong>Example</strong></p> <ul> <li><code>Site.js</code> - Responsible for the site's function &amp; operation.</li> <li><code>Ads.js</code> - Responsible for your advertisements</li> </ul> <p>You can't stop people from blocking your ads, if you try they usually just wont use your service. (Assuming you plan on ads)</p> <p>So build your graceful degradation to inform your users that your application requires JavaScript to function, you can even let them know which files are required to help ease the process.</p> <hr> <blockquote> <p>The actual 'planner' page is a whole different story though. One of the first things I was wondering about is whether or not I can use/call functions from a view. If I follow the MVC guidelines, I would say I cannot. So what I'm doing now is stacking all the data in $data arrays in my controller and then echo'ing those out through jQuery AJAX calls, straight into my webpage.</p> </blockquote> <p><strong>The key to remember is:</strong> MVC is a <em>guideline</em> not a rule. While it's best to stick to your system, you have to apply it where it's relevant. You probably shouldn't be pulling database records from your <em>view</em> but when presented with some out-of-the-box situations, it leaves you with two options: </p> <ol> <li>Break the paradigm slightly where it makes sense (for a good reason)</li> <li>Refactor your system to accomidate the paradigm</li> </ol> <p>A good example: <strong>Re-usable widget blocks like a tag-cloud or recent-posts block</strong></p> <p><em>The bottom line</em> is that you probably don't want to have to keep providing the data to <code>$this-&gt;load-&gt;vars(...)</code> or even worse in each <code>$this-&gt;load-&gt;view</code> in each controller function.</p> <p><em>One approach</em> is to re-design your system so you have a common theme library responsible for collecting common information &amp; providing it, then passing your view data (<code>$this-&gt;load-&gt;view("someview", array(),</code><strong><code>true</code></strong><code>)</code> will render your view to a string instead of the page).</p> <p><em>Another approach</em> is to design a special view that has a simple job, using a model load the relevant data (Cache if you can) &amp; display it. Like a widget, or self contained thing. <strong>This breaks MVC</strong> but you need to examine the reasons we use MVC. The key is that the view shouldn't be responsible for the implementation, this way you can swap out the view and the controller logic remains unchanged. Does that apply? this could be a highly view-implementation specific component, the controller may not know it needs this information. So if you keep a handle on it and mark it so you remember it's responsible for itself, you should be able to accommodate it just fine.</p> <hr> <blockquote> <p>Another thing I'm not sure about (AJAX-wise) is the fact that I have two different AJAX-calls on $(document).ready, and then like four more when the user clicks on different elements. It also bothers me that jQuery .html() doesn't actually put the contents inside my html tags (when I view source).</p> </blockquote> <p>This sounds like you're trying to do <strong>too much in the client code</strong>. Can any of those ajax calls @ the start be provided by the <strong>view</strong>?</p> <p>Four ajax calls when a user clicks on stuff? Most clicks represent a single action, usually only one ajax should suffice, maybe two if you need to process the response and request more information, but rarely more than that.</p> <p><code>$.fn.html(...)</code> in jQuery puts the first parameter inside the element selected. If you're looking to replace the HTML of the <em>entire page</em> (not reccomended, ever... that should be a page load). You would call this:</p> <pre><code>var theHtmlToPutInPage = "... whatever ..."; $("body").html(theHtmlToPutInPage); </code></pre> <hr> <blockquote> <p>My main problem, where I'm stuck now, is the part beneath the days. I have those 'Woe, 20 april' table headers, but then underneath that I need to get my actual events. I'm not sure what would be the best approach to creating this feature. Should I put it in a table? But then how would I put certain events on the right place? For now, all I have achieved is a function which outputs all events for a certain day into an array, like so:</p> </blockquote> <p>There are many approaches to this problem. You could build the entire thing as a big table of time-blocks, but this could get rather confusing. <em>Also, tables are nasty</em>, <a href="http://www.hotdesign.com/seybold/everything.html" rel="nofollow">There</a> are <a href="http://webdesign.about.com/od/layout/a/aa111102a.htm" rel="nofollow">many</a> well-written <a href="http://www.webdesignfromscratch.com/html-css/html-tables/" rel="nofollow">articles</a> on when &amp; where to use tables.</p> <p>You could set up the visuals as a uniform grid with CSS Divs &amp; float the appointments overtop using <code>position: absolute</code> and controlled from your <strong>Client Code</strong> (javascript).</p> <p>This is a rather complex part of your project, there's many answers and I don't have time to really deep-dive any solutions here, you'll just have to prototype &amp; experiment.</p> <hr> <blockquote> <p>I'm willing to provide a link to my source code (github) if anyone would like to take a look at my mess and perhaps try to put me on the right track again. Perhaps I AM on the right track, still; I just don't feel that way. I got stuck at the displaying-events part, and I just feel horrible because I'm not happy with what I wrote (even though most of it works, at this point).</p> </blockquote> <p>I would be willing to look it over &amp; give suggestions, as I'm sure some others here would too.</p> <blockquote> <p>As I'm on Easter break at the moment, I can't contact my teacher for another week, so I'm willing to provide a 100-150 rep bounty for a good, helpful answer to this huge rant/question.</p> </blockquote> <p>Generally bounty should be used as a motivator to get your question answered correctly. The kind of thing that gets people to go in depth (like perhaps this answer, it's getting mega long now).</p> <p>You're welcome to offer a bounty, it's your rep, however do not feel like you have to offer a bounty. If this answer is satisfactory (or any other one someone else might post, simply accepting an answer should be more than enough).</p> <hr> <p><strong>Summary &amp; Final Thoughts</strong></p> <p>Alright, so in the course of writing this monstrosity of an answer (does it count as a novella yet?) I think I may have deduced where you might be going wrong. It might be by design, but it might be accidental.</p> <p>I think you might be mistaking the view for the client code. When we talk about MVC we do not neccesarily mean, it should all be loaded in via ajax, and the view is the javascript &amp; dom running on the client's browser.</p> <p>If this is not the case, then please disregard that last paragraph.</p> <p>It really sounds like you've got the wrong weighting of responsibilities. It looks like you're tasking too much of your application to javascript. Page loads are not the devil, ajax is trendy but often can be <a href="http://blog.realmofzod.com/blog/2009/06/23/ajax-too-much-of-a-good-thing/" rel="nofollow">Too Much</a>. You have to find the right fit for your app. It really seems like you could benefit simplifying your problems by tasking more responsibility to the <strong>view</strong> instead of the <strong>client code</strong>.</p> <p>I hope this answer has helped you, sorry it took so long for me to post this, I saw your question when you posted it but didn't have the time to go in-depth like this then.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload