molly.com
Monday 7 May 2007
Molly Asks You: HTML, hasLayout and The Meaning of “Framework”
I’ve decided to ask some help with three areas I need to understand better:
- What are the most critical issues we need to solve regarding the current fragmenting state of HTML (and XHTML)?
- Please can someone explain hasLayout in two clear sentences or less?
- What does the word “Framework” mean to you?
Any input will be most appreciated!
Filed under: professional, standards, software, web design and development, WaSP, society, w3c, browsers, whatwg, molly asks you
Posted by: Molly | 5:32 pm |
May 7th, 2007 at 6:07 pm
Framework (in the context of web development, anyway): A set of tools, libraries, conventions, and best practices that attempt to abstract away routine tasks into generic modules that can be reused. This allows the designer/developer to focus on tasks that are unique to a given project, rather than reinventing the wheel each time around.
May 7th, 2007 at 6:44 pm
I’ll concur with Mr. Croft above.
May 7th, 2007 at 6:47 pm
that pretty much says it all
May 7th, 2007 at 7:10 pm
On hasLayout:
It cannot be set;
but CSS may set it;
then the reed may bend.
:-).
May 7th, 2007 at 7:11 pm
hasLayout is an MS propriety element property (not a CSS property) that determines how elements “draw and bound their content, interact with and relate to other elements”.
taken mostly from here, a very long but very thorough explanation:
http://www.satzansatz.de/cssd/onhavinglayout.html
I think hasLayout does way too many things to be summed up in 2 sentences!
May 7th, 2007 at 7:25 pm
HTML - I’ve stopped paying attention. XHTML works for me!
haLayout - arbitrary Microsoft voodoo
Framework - an abstraction of functionality that allows you to build something without understanding how it works
May 7th, 2007 at 8:15 pm
Re: hasLayout, I’ve asked Microsoft and am still trying to find the correct person to speak with. The hasLayout portion of trident just might be a mystery even articulate developers can’t explain.
May 7th, 2007 at 8:38 pm
Was thinking Microsoft should be able to explain it. If their engineers can’t, maybe they should consider introducing hasLayout to hasHandgrenade. That solution works for me.
Fragmentation in HTML/XHTML is more of an issue for “Hobby” Web content than it is for professional Web content isn’t it?
May 7th, 2007 at 8:40 pm
thacker: And my friends keep on wondering why I watch war movies over and over!
May 7th, 2007 at 8:40 pm
HTML/XTML - CCS3 or CSS2.5 would be nice. But getting the vendors to put aside their egos. Its all usual thing it comes down to ego, not a technical spec issue. The outcome of the current tech specs maybe due to the workrounds due to someones ego. But it’s people being egocentric that is the real issue.
hasLayout that annoying bug that always trips me up! Sooner it is gone the better.
Framework - standardised (not standards based) tools, methods, libraries that should allow for rapid development while eliminating the common functionality development procedures (that is its assigned to the framework).
May 7th, 2007 at 9:14 pm
Molly:
1. I am fairly new to this, and have just started seriously tracking discussions along this line. It seems to me that one of the most critical issues that need to be solved regarding the fragmenting state of HTML, is to quit fighting the fragmentation. That is, in the sense that new computer languages get developed, maybe HTML and XHTML should be fixed where they’re at, and new ways of presenting web content be developed (I know, they already are). So, no XHTML 2.0 or HTML 5.0. Start with a clean sheet, call it something different like CAMELWUFS (Created A Modernized Extensible Language Which Uses Flashy Scripts), allow it to use HTML, but don’t make it dependent on HTML. And stop mucking with something that’s pretty darn functional, html4/strict and xhtml1-strict. And the same goes for CSS, except please get the browser vendors to implement display: inline-block;
2.a. Something we shouldn’t have to use.
2.b. Ask Georg Sortun (on the CSS-Discuss list).
3. It doesn’t mean anything to me.
These questions are interesting, especially in light of Roger J.’s 5/7 posting over on 456 Berea Street, and your recent posting on POSH. I still don’t get the ’semantic’ part of semantic HTML. The microformats.org wiki definition of semantic-xhtml is circular. That is, it is self defining, and therefore to me it defines nothing. The dictionary definition of semantic or semantics means ‘meaning’ or ‘the meaning of a set of signs’. Does that mean presentational HTML is semantic because it has meaning? Are we really trying to say semantic HTML is structural HTML (a rhetorical question)? Should we stop using the term in that sense, since both structural HTML and presentational HTML are semantic? Or am I just full of crap?
Cheers,
Peter
P.S. Getting ready to POSH-up my website.
May 7th, 2007 at 9:22 pm
Molly, haven’t you SEEN haslayout? All the kids are talking about it:
http://flickr.com/photos/retrocactus/489377466/
May 7th, 2007 at 10:31 pm
Others have covered the first two. I feel the need to expand on the third, though. To a software engineer, what most people above described is simply a library or collection of libraries. A framework is distinct from a library in that it calls into your code rather than the other way around. A library provides a bunch of functions related to some problem domain that are available to your code to call as needed. A framework provides an abstract structure with “slots” where you fit your specific functionality in. A library provides an API that you can use. A framework defines an API that your code must implement and it then uses your code via that API.
There’s a lot of confusion because 1) the word “framework” has become a buzzword and as such is often mis/over-used and 2) frameworks often include one or more libraries that may not be cleanly separated so the line can get a little blurry.
The word “framework” becomes more troublesome when you get into languages that veer closer to Functional Programming territory, allowing you to pass functions or code blocks around like data (eg. in Python or Ruby) and blur the lines beyond recognition.
May 7th, 2007 at 11:47 pm
Fragmentation: Once a vendor has implemented, brought to market, and appropriately licensed feature-complete platform for next-gen markup, put it on the Recommendation track and call it a day. It’s not the way the process is designed to work, but how the process works in fact. These things happen.
hasLayout oversimplified: IE doesn’t need to guess what its dimensions are, because you told it what its dimensions should be. Not voodoo, but not common sense, either.
Framework: n. A viable reason to slough off the tedious bits of app development (because someone already did a passable job of going through the tedium for you)… at the cost of giving total strangers the responsibility of testing critical parts of the applications you write. Have a nice day!
May 7th, 2007 at 11:59 pm
I think the vendors did the right thing by splitting off from the W3C in the first instance to define things their way. Their way does make a lot of sense.
Now that the W3C has a new group that is chartered to converge with the work the browser vendors have done and all the major vendors are on board in either one group or the other the fragmentation shouldn’t be a huge problem should it?
The real problem is that the W3C as a whole should be looking to the future instead of trying to shore up the past. They should build-in a broken web, with browsers simply saying they cannot render a site if it is not based on a known standards, to force good development instead of making sure all the tag soup sites from years ago still work.
May 8th, 2007 at 12:32 am
hasLayout in two sentences:
hasLayout is a hack to increase IE’s performance so that the browser doesn’t have to figure out size and placement for every page element. If an item controls its own size and placement, it has layout; if it doesn’t control its own size and placement, it doesn’t have layout, and its size and placement are controlled by the nearest ancestor element that does have layout.
May 8th, 2007 at 1:38 am
With regards to HTML, better support for elements like object and the parsing algorithm that produces a broken DOM tree.
hasLayout is a conceptually broken implementation detail for IE’s layout model that is largely incompatible with the CSS layout model.
May 8th, 2007 at 5:29 am
As a footnote, I’d like to add this in regard to frameworks: They have an interesting learning curve all their own which seems to involve as much ethos as it does logos. The more robust the framework, the steeper the curve. And because of this, it is frequently soooooooooooooooo tempting to skirt around the very frameworks we embrace. We must be strong! To any developer who wishes to improve his/her coding and code organization best practices PLUS generally become a better person, I have two words: zope/plone.
May 8th, 2007 at 5:30 am
HTML: application/xhtml+xml most urgent
May 8th, 2007 at 6:20 am
What fragmentation in HTML/XHTML are you thinking of? If you mean quirksmode vs. standard mode, I’d say the Internet Explorer team now has one chance to introduce a new “strict standard mode switch” and when that’s done (e.g. through the new HTML5 DOCtYPE), they can’t look back and can’t have another chance to put the record straight. If they can’t implement CSS2.1 properly this time, they can’t expect the standards to help them with their buggy implementation. If they can’t work out a release schedule that allows them to fix bugs they introduce in their code, then they shouldn’t produce a browser at all. Because there will be bugs and they will need to be fixed, just as bugs in Office needs to be fixed.
hasLayout cannot be explained, it has to be experienced and learned through mind-numbing and hair-tearing effects of e.g. setting ‘zoom: 1′ (which enables hasLayout) in Internet Explorer.
I can best explain what I think of when hearing “framework” by contrasting it with the word “library”. A library is something you pull (or require) into your code to solve a subset of a problem, or a defined task. A framework, however, is a large set of idioms and rules you have to code by and that your codes “lives inside”. Ruby on Rails is a framework. A rubygem is a library. Your code lives between these two by living “inside” RoR and by requiring ruby gems to do specific tasks.
May 8th, 2007 at 6:30 am
The more fighting over this I see, the more I think that the browser makers will eventually decide for us. We might not like their choice, since there’s nothing to say they’ll choose XHTML 2 *or* HMTL 5. We might get HTML-Vista, or GeckHTML. If the standards community can’t figure something out, there’s nothing to prevent the browser makers just making up their own standards, with the bits they like plus some proprietary bits.
Personally I think I’d like to see the W3C adopt HTML 5 and add a dash (just a drizzle! not too much!) of their experience and process, wrapped in the endorsement of the recognised standards body. W3C and WHATWG both do good work.
hasLayout, or needLayout?!! actually now I’m thinking we need a LOLCAT saying “I CAN HAS LAYOUT?”
haslayout makes no sense and ruins your day whenever you forget about it.
May 8th, 2007 at 7:09 am
Molly, you probably don’t want to get the same answer as in March: “It’s a sort of ‘block formatting context’”. The term is defined in CSS 2.1:9.4.1, some of the consequences are mentioned in CSS 2.1:9.5.
http://dev.l-c-n.com/IEW/simulations.php
This is the nearest /similarity/ with something that is defined in the specification. The fact that innocent looking properties like ‘height’ do trigger a sort of ‘block formatting context’ and therefore contain floats could be seen as a conceptual violation of the specification.
Apart from containing, other aspects affect the flow, floating, positioning and layering, in short: major parts of the specification are affected by having or not having haslayout. And you are asking for two sentences or less.
The maxim is that MS can’t break the web, therefore, a question is how different from the other browser’s rendering are these aspects of haslayout at all. The answer will have direct consequences how the actual problems (both having layout and not having layout may stand for trouble) could be solved.
Setting height in IE violates the specs, so this has to be fixed if conformance is an issue. Raising the conformance affects backwards-compatibility: For what reason is haslayout mis-used?
For example, if an author decided to contain floats via display:table, and, conditionally, in IE via height, it becomes obvious that display:table should better be supported the moment height does not trigger haslayout anymore. A similar consideration can be made for the support of :after, see the clearfix-construction.
Therefore, the first answer how to neutralize the implications of haslayout and to leave the web unbroken at the same time is more CSS2.1 support. The second answer is to continue fixing bugs where currently haslayout is used to make the rendering stable enough for presentation.
In the end, the haslayout-concept has to step back into an internal layout organization structure that a designer must not have to know about, because it must not touch the rendered result by its presence or absence, merely affecting the performance of the rendering process.
I can’t believe you could not find anyone in the MS team who could explain what haslayout is. I believe that the issue is such a complex one that no one can tell for sure what implications a general fix would have. Here, for me, “Don’t break the web” means stagnation (if you want to keep haslayout as-is) or a huge step towards a full implementation of the standards (if you want to let haslayout step back).
May 8th, 2007 at 7:16 am
To me, hasLayout is kind of Microsoft’s broken implementation of block formatting contexts, as defined in 9.4.1 of the CSS 2.1 specification.
May 8th, 2007 at 7:55 am
Fragmenting state of HTML (and XHTML):
Browser makers need to first realize that the fragmenting state of HTML is due in large part to the fact that it has reached maturity and needs to grow past the days of Tim Berners-Lee. Having accepted that fact, they need a (or several) tête-à-tête among themselves, including real people who build websites, in order to decide what direction to take the standard. Everyone’s voice needs to be heard, and everyone needs to be ready to make compromises for the greater good of the standard that will serve the majority of those who use it.
hasLayout:
The hasLayout flag is set for an element whenever it is changed from its original rendered state in regards to its positioning. That is to say, hasLayout indicates that the element is no longer within the confines of or affected by the document’s normal content flow, rather it now “has layout” and is being manually manipulated via CSS.
Framework:
Code bloat, bandwidth hog, yet ease of implementation.
May 8th, 2007 at 8:06 am
There will always be “broken” Web content. There will always be tools available that create “broken” content, ie., the vast majority of the canned application development packages from GoDaddy’s tools to Dreamweaver. There is a place for “hobby” content. HTML 4 Frameset, for example, is out there, unfortunately, and it will stay regardless of HTML 5 or any other extension of HTML. Microsoft’s HTML Help Compiler SDK, chm, produces framesets and, not too mention, ignores security. [If I wanted a platform to deliver some really malicious stuff, I would have that baby in my arsenal.]
The fragmentary brand extensions of HTML, ultimately, it will be the market place that decides what has value in the same manner it decides upon the survival of the countless extensions of Oreo cookies. Market forces, for example, dictated changes within IE.
As J. Edwards stated, “XHTML works for me.”
Holzschlag–
You are such an ornery little critter, huh. That is a very good thing.
By the way I would love to read your thoughts on this HTML/XHTML fragmentation issue.
When you are hounding Microsoft on the hasLayout thing, maybe try to get a hint whether hasLayout is tightly ingrained into the Trident engine and whether or not it can be and will be broken out using the proposed “commented switch” standards mode? If it can’t be or won’t be, and Wilson’s MIX address and comment that “Trident is an excellent engine.”, which indicates that Trident will be around for a long time, then Microsoft should put together a series of white papers and examples of the effects of hasLayout and lack thereof in relation to CSS. They should present it so that it speaks in language and simplicity all the way down to eleven years olds [me].
Thank you for this blog and for the caliber of people it attracts. I am constantly reminded of just how damn stupid and ignorant I am and how very much in need I am to always acquire more and more knowledge and understanding.
J. Edwards — just finished reading your brothercake.com content. Guys like you make me look like a damn monkey. [Of course, I never ever add to that impression.] Your Web content, along with others, are valuable resources and areas that aide in understanding and learning. Such content is very much in need. Thank you.
[Sidebar] Anyone out there with the expertise to create the surfer dude Kneau Reeves plug the probe into the back of the head thing wherein he wakes up with a surprised look and states,”Wow! I know shit.”, well get to work on it. —Cause, I wanna get me one of them.
May 8th, 2007 at 8:39 am
Re: Fragmentation. Currently we see HTML 5 and XHTML 2 move in different directions. The good thing about XHTML 1.0 was it’s backwards compability with HTML 4, being a re-formulation of HTML. There are no new tags in XHTML 1.0, it’s just a matter of well-formedness and such things.
If the future brings XHTML 2 with a different set of elements and attributes than what’s in HTML 5, we are into trouble. Browser vendors have to implement two ways to interpret code, developers have to learn both, and eventually vendors will cease support of the less popular. We need reliable standards, we don’t need a format war, no BluRay vs. HD-DVD.
That said, I don’t see a future of HTML. It’s not modular to begin with. You can’t just bolt MathML or something on it, that makes the implementation of new features a tedious procedure resulting in a HTML 5.x version updates.
Anyway there can be only one future of (X)HTML. In the meantime, the complete features of HTML 4.01, XHTML 1.1 (including new modules like XHTML Role and WAI-ARIA), and CSS 2.1 must be implemented since it is the common basis for everything that follows. It is obligatory for vendors to cooperate among themselves and within the developer community (i.e. the new HTML WG) at eye-level and agree on a common interpretation of standards.
May 8th, 2007 at 8:47 am
@Martin,
But browsers don’t need to implement two ways to interpret code, as none are planning on supporting XHTML2.
May 8th, 2007 at 12:04 pm
Ingo Chao: In the end, the haslayout-concept has to step back into an internal layout organization structure that a designer must not have to know about, because it must not touch the rendered result by its presence or absence, merely affecting the performance of the rendering process.
Chao–
Can this be done within the Trident engine [with an internal re-work of the engine or whatever], reasonably and efficiently, without doing what Wilson describes as “breaking the Web”, including or using, if necessary, an author specified switch for standards mode?
Also, from what I am gathering from your post is that full implementation of CSS 2.1 by IE is restricted by hasLayout as it currently stands??
Thanks
May 8th, 2007 at 1:12 pm
The most critical issues with HTML/XHTML (and CSS + javascript.. err.. ECMA script.. err DOMscript…) is that we are in danger of getting two or three competing sets of The Standard; a bit like VHS/Betamax/Video2000 were three different standards for putting moving images on magnetic tape.
If we want to keep the web open (which means basically that my mother should be able to publish content) we need to have set of standards that not only make sense but are low-level entry (like HTML always has been).
May 8th, 2007 at 5:22 pm
Re: “Code bloat, bandwidth hog, yet ease of implementation.”
Bandwdith hog? I guess, if your framework is being passed down the pipes, then it *might* be a bandwidth hog. But many frameworks (such as back-end ones like Rails and Django) aren’t ever passed to the client at all. I suppose JavavScript libraries and CSS frameworks use up client bandwidth — but not necessarily more than would be used by writing that JavaScript directly. Right?
Same thing goes for “code bloat,” really — that all depends what framework you’re talking about. Certainly there are plenty of lightweight frameworks that aren’t bloated at all.
May 8th, 2007 at 5:54 pm
I’m concerned about where HTML 5 is heading. The way Roger tells it, there are too many loud voices saying the wrong things. I don’t know if I can trust the browser vendors enough to listen to the right people. It’s crucial that everybody can agree to a common standard or we won’t get any further ahead.
I’ve been an XHTML person since it became a W3C recommendation. I know that a lot of people don’t agree with me, but XHTML is better quality code than HTML even when served as text/html. XHTML forces you to nest elements properly, close all elements, and write elements and attributes in lowercase. Being from a programming background, these strict rules are music to my ears; nothing is worse than inconsistent source code. Serving XHTML as text/html doesn’t make it tag soup; HTML is tag soup because it doesn’t force you to be well-formed. Sure, web browsers don’t enforce well-formedness when serving XHTML as text/html, but they also don’t enforce when serving HTML as text/HTML so you’re still better off writing XHTML; the validator at least enforces well-formedness.
The reason browser vendors don’t want to implement XHTML the way it was intended is because they are scared of breaking the web, but if nobody tells people they are writing bad code they won’t see any reason to change their ways (”it works on my computer”). IIRC, somebody mentioned in a blog post recently that iCab has a nice way of letting you know you wrote bad code while still proceeding with page load. We’ve known since the Industrial Revolution that people are motivated when they can see how well they are achieving compared to those around them.
I don’t know much about hasLayout. It may have been the cause of the problems I get whenever I tried to do something fancy. What I do know is that life would be easier if we could get rid of it once and for all. IE9 perhaps?
I like Jeff Croft’s definition of a framework. I’ve personally never used a framework before because I don’t like the idea of changing the way I write code every time a new framework comes along. Learning ASP and PHP is hard enough because the documentation is not so great; some of the frameworks I’ve heard about seem to be even worse for documentation.
May 8th, 2007 at 6:00 pm
“I’ve personally never used a framework before because I don’t like the idea of changing the way I write code every time a new framework comes along.”
Then it sounds to me like maybe like you’ve actually got your own framework. A framework doesn’t have to be anything packaged up and released for public consumption. It might just be a set of conventions and chunks of reusable code you’ve you’ve come up with for yourself!
(For the record, I’d argue Django’s documentation is better than just about any open source project I’ve seen!)
May 9th, 2007 at 11:16 am
The most critical fragmentation issue is that we have two groups at the W3C who are both trying to evolve a single standard. Who are we or browser manufacturers supposed to listen to when the W3C allows two groups to evolve a single standard? The result is standards paralysis; ie “XHTML works for me.” That’s not an insult to Mr. Edwards. It’s a philosophy birthed from frustration. I share his frustration and his philosophy.
May 9th, 2007 at 11:29 am
@Jeff Croft:
In regards to Frameworks, I specifically meant JavaScript, though I suppose I should have been clear. Just because I’m a JS-head, doesn’t mean everyone else is
But yes, when someone implements a 50k+ JS library just so they can use an addClass() method or a getElementsByClassName() method… I consider that to be a waste of bandwidth. As for code bloat, granted, I did use a pretty large brush to paint that one. But there really is no way of knowing exactly how well the code you’re using is written. Unless you plan on going through every line of the Framework you choose to implement. And I’m throwing caution to the wind here, but I’m pretty sure that optimization isn’t very high on most developers lists. Then again, I am wrong on occasion.
May 9th, 2007 at 1:08 pm
Fragmentation into HTML and XHTML is necessary if the Internet, as it has evolved along with the applications that create content, is to remain an open Web with a “low-level entry that HTML provides” [as pointed out by ten Napel]?
As Kliehm noted the modular aspects and capability of XHTML, isn’t XHTML more suited for the professional developer?
What has me highly concerned more than any aspects of the questions presented by Holzschlag, is that I can foresee scenarios developing that will shut down the low-level entry because of the continued security problems that are developing. There is a significant security threat on the horizon that is developing faster than it is being addressed. Discussions of that might make for a worthwhile thread.
May 9th, 2007 at 3:58 pm
@Ara: I get where you’re coming from, but it sounds like what “framework” means to you is a pre-packaged, released set of functions and methods that someone makes available for download and you use blindly without much regard to what it actually does.
That’s not what framework means to me. To me, a framework is any collection of reusable code that makes my life easier. I’ve recently built a CSS framework, for example, to account for the things I do over and over again in web design, so that I can focus on the interesting stuff instead of the routine. I know exactly what it does and how it does it, because I wrote it. I know it’s not “bloated,” and I know that using it will ensure I stick to best practices, because they’re built into the framework.
But, the question was “what does framework mean to you?” So, I respect your answer, as it is what it means — to you. I just have a different take, I guess.
May 9th, 2007 at 10:41 pm
hasLayout puts the poles in the tent canvas.
You really can’t do much to a floppy tent, now can you?
May 10th, 2007 at 7:26 am
hasLayout in 2 sentences: A pain in the ass. Yep.
May 11th, 2007 at 9:24 am
@Jeff
I guess the cynic in me bubbled to the surface on that one. I completely agree with your approach of standardizing mundane, repetitive code. Though “Framework” wouldn’t be my first choice of name for that (though the more I use the word, the more I see how it could be acceptable). The first thing that popped into my head when Molly asked what “Framework” meant to me was a complete library of code that did everything from wash the dishes to take out the trash regardless of whether you needed it to do all that or not.
Ahhh, semantics
May 11th, 2007 at 2:58 pm
I was so taken with the enigmatic concept of hasLayout, that I adopted it as my new blog title (haslayout.com).
The idea that one secret proprietary inaccessible and poorly understood property could be at the root of so many seemingly unrelated rendering bugs struck a chord with me. It’s like the missing keystone: if someone fixed it and replaced it, the arch would stand on it’s own.
Anyhoo, my understanding of hasLayout is as follows:
It is a boolean property used internally by the IE rendering engine to determine how a DOM element affects and is effected by the DOM flow.
It is not perfectly analogous to display:block, but most would expect that it would be triggered by display:block. It often is not. As a result, people have taken to (mis)-using other properties that seem to trigger hasLayout consistently, most notably zoom:1.
May 14th, 2007 at 9:41 am
DOCTYPEs tell the browser what version of (x)html the page is coded in and therefore how to render it. If missing there is always quirks mode. As versions of (x)html progress from one to another some things get added, some depreciated. As far as I’m concerned xhtml 2 is html 5. I have read the new features of xhtml 2 and seen examples of code on IBM’s site. What am I missing? If it’s not this way, why not?
May 15th, 2007 at 7:31 am
[…] Is this wrong? Is it really a bad idea? After all the web is supposed to be a democracy of sorts. There isn’t an internet police and if everyone has a voice, then no one can complain. But it was Molly who asked only a few days ago What are the most critical issues we need to solve regarding the current fragmenting state of HTML (and XHTML)? (emphasis mine). I can’t help but think that eliminating the approach of a design by committee wouldn’t be a good start. After all, Douglas Crockford single handedly wrote the spec for JSON. […]
May 25th, 2007 at 10:06 am
Anders Pearson’s point about a Framework being something that calls your code rather than the other way round is a key point to include in any description.
HTML - it is really ‘fragmented’? I’m not so certain. Sure, there are developments in different directions, but it’s a fairly stable language that is widely used and not heavily being pulled apart.
hasLayout - I think a key part of any definition here should be that it is purely an internal structure of Trident rather than something which can be externally called. One cannot do
tagname {hasLayout: 0;}
for instance. It’s merely the way that MS engineers of yore internally factored their engine. (With any luck, it might be refactored out in the future..!)
June 2nd, 2007 at 1:53 pm
Good discussion on frameworks and their meaning. I have recently adopted CodeIgniter as my PHP framework of choice. (PHP was dictated by the client; left to my own devices, I’d be a Python/Django kinda guy.)
I chose CI principally because it’s quite lightweight. I tried Ruby on Rails and Symfony (PHP) but I found their depth (which = complexity) to become unfathomable. Any time you use a framework, you’re using (intertwingling with) someone else’s code and to the extent you don’t understand that code (or how it thinks about, e.g., directory structure), the more you feel like you’re programming in the dark.
That was always my biggest challenge with my all-time favorite language cum framework, Smalltalk.
March 7th, 2008 at 1:27 pm
thanks molly
March 17th, 2008 at 7:25 am
thanks
March 30th, 2008 at 10:27 am
thanks
April 22nd, 2008 at 7:56 pm
Nice job.
April 22nd, 2008 at 7:56 pm
Thanks,very nice blog.
July 24th, 2008 at 11:36 am
good sitee
July 24th, 2008 at 12:15 pm
good blogger
July 24th, 2008 at 12:42 pm
thanks web site
July 24th, 2008 at 3:35 pm
very nice