If only reality worked that way!Designers shouldn't be touching markup. Designers use CSS, plus images (Photoshop etc.)
Do your designers also create your XML feeds? (RSS, Atom, Sage, etc)
On Frameworks, RoR & PHP
Moderator: General Moderators
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
Last edited by Ambush Commander on Fri Jun 29, 2007 6:19 pm, edited 1 time in total.
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
When I make websites, I end up doing the designing, implementation, etc. all by myself, so I have a lot of leeway in this respect. HTML Purifier's website is probably one of the most semantic you're going to get there on the web.
But I have no interest in implementing a forum, so I rolled Phorum for my website. It works reasonably well, but there's a lot that could be improved. But, then again, I have no interest in reimplementing an application (note, I have been coordinating with the Phorum developers for specific little issues that I've been running into)
But I have no interest in implementing a forum, so I rolled Phorum for my website. It works reasonably well, but there's a lot that could be improved. But, then again, I have no interest in reimplementing an application (note, I have been coordinating with the Phorum developers for specific little issues that I've been running into)
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Sorry but I have to call nonsense. How can you not "touch markup" and at the same time "use CSS" when CSS styles the markup. I think you are bandying a little too much. If you only let your designers edit the stylesheet then I think you are too involved.Jenk wrote:Designers shouldn't be touching markup. Designers use CSS, plus images (Photoshop etc.)
Yes, using tools ... just like they use tools to create HTML.Jenk wrote:Do your designers also create your XML feeds? (RSS, Atom, Sage, etc)
I suppose I could say that I cache to markup language output in usable chunks and then assemble the response from mostly build pieces at run-time.
(#10850)
Well actually that is almost exactly what I am saying.arborint wrote:The original argument was a straw man because I have never heard anyone say that you should have all meaningful URLs. It is as silly as me saying that ev0l is proposing than no URL has any human readable meaning at all.
You and I may understand the meaning or intention of a URL, and its arguments, but the vast majority of users do not. While urls should have meaning in order to assist your web browser in bookmarking, there usefulness to an enduser is almost nil.
To an enduser meaningful URLs are meaningless.
In fact templates are worse. They greatly hinder reusability. I could envision a component biased template system that played well with reusability but in that situation templates would clearly be painful to manage. Programatic HTML generation just makes much more sense in an AJAX driven world.arborint wrote:They don't take any of my time. A designer builds the layout templates and the site owners directly edits the content templates (WYSIWYG) -- I rarely touch any of them. Mostly I am involved in defining the initial CSS and they take it from there.Jenk wrote:Templates are the age of the dinosaur. Until you stop using them it's very difficult to see this. They are a waste of developers time, when the developer could be using a markup generator that can easily switch between (X)HTML, XML, even plain text - where you would normally need a template for each.
In essence: you think Java is leading the way in terms of web-based languages like PHP? I'm not an expert on Java (nor JavaBeans either) - but basically, PHP is and always has been a somewhat wild stepchild of C and Java that ran away from home. So, you're saying, it's time to "come home" in terms of features and application architecture?ev0l wrote:Like Seaside and Phaux .arborint wrote: That's why I think it might be interesting to have a discussion about how the third generations of PHP frameworks might be designed.
I think the next generation of frameworks are going to have some fundamental similarities.This is going to mean the death of...
- Statefulnes.
Callbacks.
Highly reusable component architecture.
HTML being generated programatically with a heavy reliance on CSSStateful frameworks that have highly reusable component architectures will finally fulfill the full power of object oriented programming in the web development space.
- Templates
"Meaningful" URL's that have no meaning
Traditional MVC
Page based development (it will just be components embedding or calling other components using callbacks)
Mentioning Java to a Smalltalk developer is somewhat of an idiom - there is some political bad blood between them, and Java is only now implementing features that Smalltalk has had for 30 years. Smalltalk has changed very little since the 80's, and tbh - that's not because of slow development or progression, it's because Smalltalk had it right from the start.
Biased as hell, but only because I've been using Smalltalk since the beginning of this year and I have full confidence that it is correct.
Biased as hell, but only because I've been using Smalltalk since the beginning of this year and I have full confidence that it is correct.
In terms of lineage, could well be that Smalltalk is the forebear, but to look condescendingly on everything that follows would mean that Smalltalk should be perceived as the beginning - which it isn't. Like everything else, it stands on the shoulders of giants.Jenk wrote:Mentioning Java to a Smalltalk developer is somewhat of an idiom - there is some political bad blood between them, and Java is only now implementing features that Smalltalk has had for 30 years. Smalltalk has changed very little since the 80's, and tbh - that's not because of slow development or progression, it's because Smalltalk had it right from the start.
Biased as hell, but only because I've been using Smalltalk since the beginning of this year and I have full confidence that it is correct.
My question is a bit broader than what you make it out to be. Following on from the initial question "Where will PHP go?", I'm asking whether it's bound to follow it's parentage - as ev0l seems to suggest.
It doesn't. You're missing some of the finer points.Jenk wrote:That still bounds back to the same point.
1. What is so "right" about Smalltalk that makes it the alpha & omega?
2. Does PHP's user-base have anything to do with the direction PHP is developing?
3. Why is PHP bound to go down the Smalltalk route - esp. reg. question 2?
To make it clear: this is not a Smalltalk vs. PHP question. It's simply a question about language-inherent features, the "natural" environments of the languages etc.
To say "Smalltalk's got it right" is a clear opinion, but you'll need to add some facts to that as to why PHP is bound to down that route (question 3).
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
I think you have never had to do tech support and ask a user to type in a URL. Saying that no URLs are meaningful and that users do not look at them -- is simple not true in my experience.ev0l wrote:Well actually that is almost exactly what I am saying.
You and I may understand the meaning or intention of a URL, and its arguments, but the vast majority of users do not. While urls should have meaning in order to assist your web browser in bookmarking, there usefulness to an enduser is almost nil.
To an enduser meaningful URLs are meaningless.
Again you can make statements, but you need to prove it. And I am really not sure how germane "reusability" is to content -- which is rarely duplicated. In layout driven systems there is total reuse of common elements. Templating merely caches the generated content. And I freely admit that templates do not work for everything and almost always include generated content.ev0l wrote:In fact templates are worse. They greatly hinder reusability. I could envision a component biased template system that played well with reusability but in that situation templates would clearly be painful to manage. Programatic HTML generation just makes much more sense in an AJAX driven world.
(#10850)
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Everything is an object even classes, image based development, the language is integrated with an IDE giving you method/object categories, hierarchical class browser, category class browser, package class browser, access and ability to change or expand every object in the system, self documenting syntax, code blocks, methods are compiled individually when they are saved in the IDE, completely cross platform, message passing, support for real polymorphism, code blocks ....patrikG wrote:
1. What is so "right" about Smalltalk that makes it the alpha & omega?
The list goes on.
Absolutely and that is not a good thing. PHP5 had a real opportunity to do the right thing with OOP and instead they copied Java. Java is a miserable, untrusting language that poorly and incompletely implements some of the most important aspects of OOP. Java did this mostly in the name of safety, the belief that the programmer can't be trusted.patrikG wrote: 2. Does PHP's user-base have anything to do with the direction PHP is developing?
It's not. I am not to sure who implied this but I think there might be a communication error.patrikG wrote: 3. Why is PHP bound to go down the Smalltalk route - esp. reg. question 2?
I think that the future of framework development will be heavily influenced by Seaside. Seaside follows a natural progression in programming tools. Abstracting the developer away from the nitty dirty of the process, making them more productive, and gaining things developers see as advantages like reusability.
There are things you can do in Smalltalk that you can not do in PHP. The inverse is not true. In my book that makes Smalltalk more powerful. Don't get me wrong I still use and enjoying using PHP but PHP is not and will never be as influential as Smalltalk.patrikG wrote: To make it clear: this is not a Smalltalk vs. PHP question. It's simply a question about language-inherent features, the "natural" environments of the languages etc.
To say "Smalltalk's got it right" is a clear opinion, but you'll need to add some facts to that as to why PHP is bound to down that route (question 3).
No Smalltalk is the giant. You may not perceive Smalltak as the beginning of OOP but history tells us it is.patrikG wrote: o
In terms of lineage, could well be that Smalltalk is the forebear, but to look condescendingly on everything that follows would mean that Smalltalk should be perceived as the beginning - which it isn't. Like everything else, it stands on the shoulders of giants.
Actually Smalltalk has a number of major finical firms behind it. The language did in fact take off but its usage declined after the introduction of Java. Java, and Sun, were very successful at something most Smalltalk venders were not, public relations.arborint wrote:Smalltalk?!? There were probably 100 Smalltalk programmers working on real projects -- maybe 101 now with Jenk if he is really using it for a actual paying project. It is a language that hasn't taken off, even with the likes of Beck and Fowler trying to make it work....
But all of that is beside the point. Just because adoption of Smalltalk is not as large as Java does not mean that there is nothing you can learn from the language.