Page 4 of 10 FirstFirst 12345678910 LastLast
Results 31 to 40 of 99

Thread: Requirements for a Web Front End

  1. #31
    Antenna Engineer
    Auto Apps:loading...
    optikalefx's Avatar
    Join Date
    Apr 2009
    Location
    Baltimore, Maryland, United States
    Posts
    837
    Blog Entries
    86
    I don't think people will like us giving them a skin creator. Some people might. But that should be an after thought, just swapping out CSS files is the developer way, and you get way more freedom than we could possibly offer in a gui.

    checkout http://www.csszengarden.com/

  2. #32
    Admin. Linux loser.
    Auto Apps:loading...
    Bugbyte's Avatar
    Join Date
    Sep 2004
    Location
    Corning, NY
    Posts
    7,359
    Blog Entries
    2
    Yeah! Like in your link! +1 for something like that.
    Quote Originally Posted by ghettocruzer View Post
    I was gung ho on building a PC [until] just recently. However, between my new phone having internet and GPS and all...and this kit...Im starting to have trouble justfiying it haha.
    Want to:
    -Find out about the new iBug iPad install?
    -Find out about carPC's in just 5 minutes? View the Car PC 101 video

  3. #33
    Mod - all of it. SapporoGuy's Avatar
    Join Date
    Aug 2009
    Location
    SonyLand
    Posts
    448
    I finally got some sleep

    what if we put another layer into ice/nghost?
    Instead of it having print to screen it outputs to a browser?
    I really would like to build off a distro that is being developed for a small foot print and if possible already has most of the base ready to go.

    Once the beta is out we could start looking at a solution if need be.


    Another thought I had was after not really giving songbird a chance was to actually look at how songbird could be expanded upon to access more of the lower level system apis. However this might block the web developer ease if use.


    Optiflex,
    what do have available that we could start off?
    I was thinking that to some extent we could kill 2 birds with one stone and loose zen

  4. #34
    FLAC sama's Avatar
    Join Date
    Feb 2006
    Location
    London, UK
    Posts
    1,375
    Agreement all around to the above ideas.

    Apologies if this is obvious already, but a really important point that must be stressed is that for this to work well like it does with the infamous CSS Zen gardens, the separation of concerns principles need to be adhered to. In web design, this manifests itself as follows:

    HTML = Markup and only markup. That's (dynamic) content and the markup around the content that classifies it. No presentational markup in here or styling.

    CSS = Presentation and only presentation. That's the styles for the classes of markup.

    JS = View logic and view logic only. That's manipulation of data that's received from the services/user so that it can be displayed/interacted with. Things like gestures, or organising lists etc.

    JS & Markup: What you don't want to do here is generate markup. This is a very common mistake as it's a shortcut that people take. Having markup spread across the HTML and JS makes it difficult to maintain. You'd use templates and DOM manipulation instead.

    JS & Styling: What you also don't want to do is have the styling come from here. You can show/hide elements or add/remove classes, but all style definitions must come from the CSS.

    JS & Services: JS is a powerful programming language that can do a lot and you could arguably write some JS services that sit at the bottom of the view stack, meaning it's almost like the server just at the client. This blurry line needs to be done with care if at all as it spreads the service layer between the server and the view and concerns are then distributed. In my opinion this is a bad design and services should be centralised on the server.


    If you stick to the above rules, then a concept like CSS zen gardens for frontends will work.

    Just my 3 pence

  5. #35
    FLAC sama's Avatar
    Join Date
    Feb 2006
    Location
    London, UK
    Posts
    1,375
    Opera looks like an excellent starting point!

  6. #36
    Maximum Bitrate Crinos's Avatar
    Join Date
    Mar 2009
    Location
    Kristiansand, Norway
    Posts
    483
    Quote Originally Posted by sama View Post
    Agreement all around to the above ideas.

    Apologies if this is obvious already, but a really important point that must be stressed is that for this to work well like it does with the infamous CSS Zen gardens, the separation of concerns principles need to be adhered to. In web design, this manifests itself as follows:

    HTML = Markup and only markup. That's (dynamic) content and the markup around the content that classifies it. No presentational markup in here or styling.

    CSS = Presentation and only presentation. That's the styles for the classes of markup.

    JS = View logic and view logic only. That's manipulation of data that's received from the services/user so that it can be displayed/interacted with. Things like gestures, or organising lists etc.

    JS & Markup: What you don't want to do here is generate markup. This is a very common mistake as it's a shortcut that people take. Having markup spread across the HTML and JS makes it difficult to maintain. You'd use templates and DOM manipulation instead.

    JS & Styling: What you also don't want to do is have the styling come from here. You can show/hide elements or add/remove classes, but all style definitions must come from the CSS.

    JS & Services: JS is a powerful programming language that can do a lot and you could arguably write some JS services that sit at the bottom of the view stack, meaning it's almost like the server just at the client. This blurry line needs to be done with care if at all as it spreads the service layer between the server and the view and concerns are then distributed. In my opinion this is a bad design and services should be centralised on the server.


    If you stick to the above rules, then a concept like CSS zen gardens for frontends will work.

    Just my 3 pence
    +1

    Only thing I would like to add is server side script/programing like ASP and PHP.

    PHP can do fantastic things, and is fairly easy language to master.
    Hook it up with lets say, Google Maps API, and you would have a great mapping/navigation program. Only thing you would miss is guidance voice by Homer Simpson or Darth Vader (kudos to TomTom).

  7. #37
    Mod - all of it. SapporoGuy's Avatar
    Join Date
    Aug 2009
    Location
    SonyLand
    Posts
    448
    I'm gonna agree with the opera idea!
    can we embed this into linuxIce?

  8. #38
    Maximum Bitrate Crinos's Avatar
    Join Date
    Mar 2009
    Location
    Kristiansand, Norway
    Posts
    483
    Quote Originally Posted by SapporoGuy View Post
    I'm gonna agree with the opera idea!
    can we embed this into linuxIce?
    http://www.opera.com/download/index.dml?platform=linux
    Guess you can

  9. #39
    Mod - all of it. SapporoGuy's Avatar
    Join Date
    Aug 2009
    Location
    SonyLand
    Posts
    448
    Looks like I'm gonna install a virtual machine to test some of this out.

    Looks like we have:
    OS: LinuxIce
    GUI layer: opera, html5, jquery, CSS
    lower layers: existing nghost, velocity/java
    catchy key words: agile and rapid development, MVC, best of coding practices, code once deploy all

    we still need to consolidate base user functions, so:
    media player
    navigation
    Bluetooth
    OBD
    and anything that is available on the web

    we should also start deciding on the lower level API usage section too

  10. #40
    FLAC sama's Avatar
    Join Date
    Feb 2006
    Location
    London, UK
    Posts
    1,375
    Quote Originally Posted by Crinos View Post
    Only thing I would like to add is server side script/programing like ASP and PHP....
    Yep, for sure, you need the HTML to be the dynamic so server side generation is essential for templating.... or do you?

    Quote Originally Posted by Crinos View Post
    Isn't that the browser as opposed to the CDK? CDK is here

    Quote Originally Posted by SapporoGuy View Post
    Looks like I'm gonna install a virtual machine to test some of this out.

    Looks like we have:
    OS: LinuxIce
    GUI layer: opera, html5, jquery, CSS
    lower layers: existing nghost, velocity/java
    catchy key words: agile and rapid development, MVC, best of coding practices, code once deploy all

    we still need to consolidate base user functions, so:
    media player
    navigation
    Bluetooth
    OBD
    and anything that is available on the web

    we should also start deciding on the lower level API usage section too
    CDK's probably the first thing to toy with to determine what it can actually do.

    As for using Velocity, it was actually developed and tested on Windows. I've just gone through the code briefly and I'm thinking it may actually take quite some tinkering to get it doing what you want it to do from the above discussion. So here's what I'll do:

    I'll quickly knock up Velocity 2.0alpha - this will be grails app with DWR enabled that exposes the Java File API. I should have it ready within a week or so.

    What this means is that you'll be able to make calls like this from JavaScript:

    Code:
    FileService.listRoots( {
    	callback: function() {
    		updateFileList();
    	}
    });
    I'll host it on the EC2 cloud so people can toy with it and see.

    On Agile... I'm a Java developer turned Scrum Master

Similar Threads

  1. How to: Change windows shell
    By IntellaWorks in forum WinNT Based
    Replies: 44
    Last Post: 04-12-2012, 08:29 PM
  2. EniCar the RR Clone
    By enitalp in forum Software & Software Development
    Replies: 296
    Last Post: 12-13-2008, 06:12 PM
  3. yet another Front End!
    By natedawgg in forum NASAir
    Replies: 50
    Last Post: 06-06-2008, 11:00 AM
  4. New front end
    By alienmanfc6 in forum Other Cool Front Ends
    Replies: 3
    Last Post: 03-30-2008, 09:57 PM
  5. Replies: 20
    Last Post: 11-11-2006, 11:07 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •