CSS dinamycally manipulated
Locked
RE: CSS dinamycally manipulated
 
|
Hi there,
I've asked for this subject so
is fear that I tell what I think. As I see things, this is just another style to
discuss an old thing again: the convenience of coupling a model domain and a
view domain.
Let's understood this one step
ahead: for Seaside developers, browsers should be considered mere hardware.
The application is the Model and WAComponents are some sort of "proto views"
that serializes (aka render) in html and should be the preamble of the
generation of the views (view objects). In this framework, internet will be just
a convenient bus of the system.
All outside Seaside, you will find
(now in 2007) the View part of the framework full of holes, this is, with lack
of the completenes that one is used to enjoy in smalltalk (and it should have no
matter tech is about). The CSS solves, yet incompletely, only the satic layout
part of the View. If you need dynamic layout you will feel CSS small or
incomplete (not to mention incompatible for some browsers). Here the javascript
Prototype framework can help.
I'm working this days on a little
framework of my own, made (one part) in javascript based on Prototype, to
have in the browser js objects that are homologous instances to the Seaside
components (match 1:1). This way I hope to be able to manage elegantly and
masively but with minimal st inteligible code 99,9% from smalltalk 1) the event
wiring of the seaside components and the matching elements in browser,
2) the actions (defining defaults for everything and specializing just what
is needed) of those events specifically in a "non hakish" style, 3)
factorization of all this in one rich convenient hierarchy, 4) A step forward in
the fullfill of those holes outside smalltalk to reach reasonably the objetive
of completeness of Views objects for web applications.
cheers,
_______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
RE: CSS dinamycally manipulated
|
|
In reply to this post by Jason Johnson-3
The point people are trying to make (IMHO) is that adding CSS
canvas/brushes akin to existing HTML canvas/brushes is not going to be a priority for core Seaside developers simply because this seems very niche type of functionality at the moment and they would rather focus on core elements that make Seaside appealing. That's not to say one couldn't do it, I've added a similar thing to build up chart data in XML and it's not rocket science per se, so there's no reason for someone who needs it to avoid doing it themselves if they care to, (xml column2D) caption: 'Recent Activity (10 days)'; yAxisName: 'Volume'; labelDisplay: 'stagger'; rotateLabels: true; slantLabels: true; with: [dates do: [:date | (xml set) color: '8678f2'; label: (date printUsing: 'ddd, mmm dd, yyyy'); value: (somevalue)]] Cheers! -Boris -- +1.604.689.0322 DeepCove Labs Ltd. 4th floor 595 Howe Street Vancouver, Canada V6C 2T5 http://tinyurl.com/r7uw4 [hidden email] CONFIDENTIALITY NOTICE This email is intended only for the persons named in the message header. Unless otherwise indicated, it contains information that is private and confidential. If you have received it in error, please notify the sender and delete the entire message including any attachments. Thank you. > -----Original Message----- > From: [hidden email] [mailto:seaside- > [hidden email]] On Behalf Of Jason Johnson > Sent: Sunday, June 10, 2007 10:19 AM > To: Seaside - general discussion > Subject: Re: [Seaside] CSS dinamycally manipulated > > Ramon Leon wrote: > > Been there, done that, doesn't work, designers don't like code, and > > programmers don't like the code generated by ANY fancy graphic front > > program. Design doesn't belong in code and code doesn't belong in > design. > > CSS and HTML work quite nicely. > > > > The last thing I want is another dreamweaver/flash thingy that writes > > horrible Smalltalk code in Seaside that I have to work with. CSS > doesn't > > belong in code. > > > > So you're saying designers shouldn't use "fancy graphic front end's" and > just write everything by hand in CSS? You can't be serious. > > Anyway, it doesn't matter what you, I or we on the list think people > *should* be doing, there are people who *do* want to do such things. > The reason systems like Joomla are popular is because designers can > design the site from within the site. > _______________________________________________ > Seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
RE: CSS dinamycally manipulated
|
|
In reply to this post by Jason Johnson-3
<tongue-in-cheek>
You are joking about expensive editors, aren't you? :) Let's look at two most popular CSS editors in terms of developer time at $60/hr, http://macrabbit.com/cssedit = $29.95 = 30 minutes http://www.newsgator.com/Individuals/TopStyle = $79.95 = 80 minutes I bet if they cost 10 or 20 times more, I'd still let my designer expense it, wouldn't you? </tongue-in-cheek> Cheers! -Boris -- +1.604.689.0322 DeepCove Labs Ltd. 4th floor 595 Howe Street Vancouver, Canada V6C 2T5 http://tinyurl.com/r7uw4 [hidden email] CONFIDENTIALITY NOTICE This email is intended only for the persons named in the message header. Unless otherwise indicated, it contains information that is private and confidential. If you have received it in error, please notify the sender and delete the entire message including any attachments. Thank you. > -----Original Message----- > From: [hidden email] [mailto:seaside- > [hidden email]] On Behalf Of Jason Johnson > Sent: Saturday, June 09, 2007 1:35 AM > To: Seaside - general discussion > Subject: Re: [Seaside] CSS dinamycally manipulated > > Ramon Leon wrote: > >> I think CSS has to become a first class citizen (like HTML) > >> first, no? :) _______________________________________________ > >> > > > > No. Designers aren't programmers and programmers aren't designers, > they > > never will be. > > > > Designers don't want dynamic CSS, and programmers have already lived > through > > having our dynamic markup (HTML) abused for design, why would we to go > > through that again? Making CSS a first class citizen doesn't give > designers > > more options, it gives programmers more work. > > > > _______________________________________________ > > Seaside mailing list > > [hidden email] > > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > > > > > Ah but you're thinking about just one possibility. If CSS were first > class and easily manipulatable, then it would be possible to make a > builder directly in Seaside. Then your company doesn't have to buy > expensive software to allow designers to style your pages. > > > Having more options to do something doesn't give anyone more work unless > they choose to have more work. > _______________________________________________ > Seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: CSS dinamycally manipulated
|
|
Boris Popov wrote:
> <tongue-in-cheek> > > You are joking about expensive editors, aren't you? :) Let's look at two > most popular CSS editors in terms of developer time at $60/hr, > > http://macrabbit.com/cssedit = $29.95 = 30 minutes > http://www.newsgator.com/Individuals/TopStyle = $79.95 = 80 minutes > > I bet if they cost 10 or 20 times more, I'd still let my designer > expense it, wouldn't you? > > </tongue-in-cheek> > > Cheers! > > -Boris > > could have the same level of flexibility one could have from within Seaside. For example, if CSS became a first class option [1] and a WYSIWYG style editor was made to replace the style editor we have now (that big box that just dumps CSS text into a class side method) then the editor could let one design components [2] individually. This way, since the style is something the component itself carries with it, the component would look how the designer styled it no matter where it wound up in the web application. And if a developer used an old component again in a new set of pages, it still has the same look the designer gave it originally. There are a lot of options here, and if no one else is ever interested I will eventually do it myself because for me and the designers I work with it would just be too useful not to do. [1] NOTE: This isn't me trying to put work on Philippe or Lukas' plate. This isn't a priority for them as you stated earlier, and I don't blame them at all. This is just me expressing an idea I don't have time to do right now in case someone else found it interesting [2] By component I mean a class or group of classes that make up some functionality that can stand on it's own. Examples: a calendar, the counter, the page display functionality in the sushi store, a big bold dynamic page title, a PRWidget, etc. _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
RE: CSS dinamycally manipulated
|
|
> >
As I've said, I'm pro this. The way the components look should be
> > > But since these aren't integrated with Seaside I don't see > how they could have the same level of flexibility one could > have from within Seaside. For example, if CSS became a first > class option [1] and a WYSIWYG style editor was made to > replace the style editor we have now (that big box that just > dumps CSS text into a class side method) then the editor > could let one design components [2] individually. This way, > since the style is something the component itself carries > with it, the component would look how the designer styled it > no matter where it wound up in the web application. And if a > developer used an old component again in a new set of pages, > it still has the same look the designer gave it originally. > > There are a lot of options here, and if no one else is ever > interested I will eventually do it myself because for me and > the designers I work with it would just be too useful not to do. > > [1] NOTE: This isn't me trying to put work on Philippe or Lukas' > plate. This isn't a priority for them as you stated earlier, > and I don't blame them at all. This is just me expressing an > idea I don't have time to do right now in case someone else > found it interesting [2] By component I mean a class or > group of classes that make up some functionality that can > stand on it's own. Examples: a calendar, the counter, the > page display functionality in the sushi store, a big bold > dynamic page title, a PRWidget, etc. > controllable (and reusability allowed) by designers. So an integrated seaside "resource" (I mean the View part) editor is desirable. The problem could came for experience architects or experience designers who also will wish to be able to experiment behavior to confirm if the application's usability experience they have planned/imagined are confirmed pragmatically. Behavior implies code. Reuse of components as if they where widgets could make this feasible I think. Cheers, Sebastian _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
| Free forum by Nabble | Edit this page |