Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
PHP Programming

Meet The New PHP5 Toolkit, Pidget 66

Posted by timothy from the wait'll-you-meet-my-pidget dept.
Squirrel482 writes "People who like toolkits like QT and GTK but are generally ticked of by the state of GUI design on the web should check out Pidget. It is a just released GUI toolkit (along the lines of QT for the web) for PHP5. It features good object oriented design and is probably one of if not the first publicly available project to take advantage of PHP5. It's in early development and is still a little rough around the edges, but definately worth checking out."
This discussion has been archived. No new comments can be posted.

Meet The New PHP5 Toolkit, Pidget More

Meet The New PHP5 Toolkit, Pidget

Comments Filter:
  • This looks like it could be really useful in the long run. I hope that it will let me avoid mixing so much PHP with Javascript for widget/form stuff. Anything to make that mixed code easier to read is a blessing. I'll be using the toolkit right away.

    On a side note, does anyone see any security problems with the code so far? That's my only real worry. Also, should someone build some DB classes and hooks into this for an all-in-one type of addition. PHP can begin to be an include mess after a while (see pr

  • Amazed (Score:2)

    by 4of12 ( 97621 )

    ...that a server side widget toolkit is a usable thing.

    All my instincts tell me that network latency and screen refreshes would be much better done if the widget manipulation were client side. And I'm sure this is still the case.

    That this kind of thing is used is a testiment to how client-side web widgets have not been living up to their potential. Security problems, perhaps (ActiveX)? It's not like PHP applications come in with a squeaky clean reputation on the security front, either...

  • Looking forward to using this once it sufficiently maturizes (i'll have to try and see how mature it really is).
  • Pidget sounds a lot like Java ServerFaces [sun.com] so it's nothing new. What I find annoying is that the "best" way to make a dynamic site keeps changing. Last week it was to have your site generate XML and use style sheet translation, this week it's to assemble objects on the server and have the server convert all the objects to html.

    • "What I find annoying is that the "best" way to make a dynamic site keeps changing."

      Maybe because there is no "best way"...

      There is significant impedence mismatch between an interactive GUI and a server-side-generated UI, these frameworks are just a way to cover it up. What is really needed is some sort of universal declarative UI language - and again, there are several contenders (XPCOM/XUL for example, Tim Berners Lee is pushing cURL, which is a mixed UI/content language), but there is no current stand
    • The best way is to simply keep the data away from your view. That way, you can replace one without having to affect the other unless your business logic changes.

      XML + XSLT, some teplate engine..

      assembling objects and then converting it to HTML is no more efficent, but if you want to move a submit button from the bottom of your screen to the top, you affect both.

      • XML + XSLT, some teplate engine..

        That's exactly what I do, from content to presentation:

        • xml Data
        • xsl
        • css

        For software, it's Apache / PHP / sabolotron / and movable type to generate the xml

        The following helps, too:

        Action proc-xml /path/to/handler.php
        Addhandler proc-xml .xml
    • Don't make the mistake of equating 'newest' with 'best.'
  • How is the stability on PHP5 doing? I haven't gotten to try it out just yet, but this interests me. The stability of this library also interests me of course! :)

    Any user opinions there?
  • I checked out the site, and it seems that all of this could be done in plain old CSS. Why change PHP code at all when you can alter the look/position of the widgets in CSS and be done with it.

    While most people plop presentation logic in with their PHP code doesn't mean it is the best way to do it. Use PHP to generate XHTML and use CSS to alter the presentation. No javascript needed, no multiple versions of a site for various browsers, no special "light" edition... handle it all in CSS.

    Use standards, peopl
    • Yep, then all we need is for the most popular browser (by far) to correctly support CSS.

      I'll hold my breath, for I look good in blue. :)

      • For the most part, IE 6 supports CSS "well enough". It is possible to create a site that uses XHTML Transitional and CSS that degrades well on all browsers [including the cursed NS4].

        The real problem is that UI designers and programmers want to do what they know how to do, rather than consider the alternative.

        Take a look at the following sites for additional information:

        • The key phrases you used are "For the most part" and "well enough." Having done far more than my fair share of XHTML & CSS work, I know that IE6's CSS implementation is just funky enough to cause problems. Part of the problem may be that I'm overly picky. I want it to actually work as it _should_. *shrug*

          • Yes, I did use those words for a reason, but think about it...

            Does it make more sense to create an XHTML/CSS site that can work on *every* browser, even if degraded, or a site that only works on 1 browser, and breaks when you want to update it?

            There are many many ways to "hack" the CSS to make things work with IE and the "broken box model". Of course, you shouldn't have to "hack" anything, but that isn't the current reality.

            If Wired* and ESPN* and others can pull off complex XHTML/CSS based sites, pe

            • > Does it make more sense to create an XHTML/CSS site that can
              > work on *every* browser, even if degraded, or a site that only
              > works on 1 browser, and breaks when you want to update it?

              Those aren't the only choices available, though.

              Depending on how often a site is updated, XHTML/CSS may not be necessary for ease of maintenance. When that is the case, I can often make something work pixel-perfect & identical on just about any browser by using plain ole HTML 4.01. If one has to make a bunch o

              • Yes, you can make pixel perfect layouts in HTML 4.01 that will work in Netscape and IE.

                But what about other browsers, like the browser on your Palm, or the browser hooked into a screen reader, or webTV? Does the layout scale? With CSS it does, both up and down.

                I agree with you, in that if you don't update your site, it really doesn't matter what HTML version you code against. But what happens when you want to update your look, but keep the content? You could change your CSS once, in one place, and hav

                • > But what about other browsers, like the browser on your Palm, or the browser hooked into a screen reader, or webTV? Does the layout scale? With CSS it does, both up and down.

                  If I know it's going to be something used with those, yeah, I can make them scale pretty well.

                  > I agree with you, in that if you don't update your site, it really doesn't matter what HTML version you code against. But what happens when you want to update your look, but keep the content?

                  That depends on how you manage your cont

                  • First, I'd like to say, I am enjoying this thread. It's nice to have a rational conversation with someone who can create a good argument. Thanks!

                    regarding odd user-agents:

                    If I know it's going to be something used with those, yeah, I can make them scale pretty well.

                    But isn't that the point? you'll never know how people will view your site. Wanting to deliver content to everyone is a good idea. Why shut someone out? I've said it before, but with CSS you can deliver appropriate content to a user-agent.

                    T

                    • point of clarification:

                      The removal of the tag alone saves quite a bit on each page delivery.

                      should read:

                      The removal of the <font> tag alone saves quite a bit on each page delivery.

                      The Slashdot filter nuked it

                    • Is some of the stuff proposed in xHTML 2. I really want to write and serve RDF as my default content type on my site, while transforming it to xHTML for user agents not NetNewsWire / Amphetadesk, but a lot of the fields that RDF uses have some interesting near-equivalents in the next xHTML. Also, I'm really looking forward to object fallback where an video falls back to an image, which falls back to text if need be. Nice stuff, and good for semantics and screen readers.

                    • While I understand what you are saying, and while this idea doesn't *quite* fit your problem, The theory is that you can do this [DRF/RSS to XHTML] today, via server-side XSLT.

                      I too am looking forward to <object> tags and what they can do. I think it will streamline the whole plug-in process.

                      Having MS decide that they will not update IE prettymuch prevents anyone from adopting it though. Gods, I hate monopolies. The only think I can think of to "break" the MS stranglehold is to purposfully make mark

                    • Actually, I'm having problems with sabolotron and alternate namespaces inside of a file, so i'd rather go xml->rdf xml or xml->xhtml based on user agent.

                      By alternate namespaces, I mean any root tag with an xmlns declaration in it. sabolotron cannot grab one of these as a root node, and instead takes whatever the default action is in the xsl file. Took me quite a while to find this problem, and it was frustrating to try to work around it.

                  • If I know it's going to be something used with those, yeah, I can make them scale pretty well. If your content isn't coming out of a database, then your code needs to be designed for easy cut and paste. No, it's not pleasant, but you can do a relatively straightforward template change within a day on sites that have hundreds of pages, if you've done your work correctly. With CSS you can make one change that will apply to hundreds of pages now, and hundreds in the future, regardless of the initial use of t
                  • If your content isn't coming out of a database, then your code needs to be designed for easy cut and paste. No, it's not pleasant, but you can do a relatively straightforward template change within a day on sites that have hundreds of pages, if you've done your work correctly.
                    Or just 1 minute if you did it with server-side includes, or use sed or a text editor that supports running a regular expression replacement through multiple files at once (e.g. UltraEdit on Windows).
            • Yes, considering the fact that the '&' in urls should be a ';', they are a bit behind the times. Perhaps it's time to toss the circa-1996 'CGI Programming Unleashed!' bible and move to something a little more recent.
          • ONE TIP: use the STRICT DTD declaration and it will get IE to work alot more like other browsers as far as CSS goes. If you don't delcare, use loose or traditional, then there's a world of difference between IE CSS & other CSS implmentations.

            But if you do this, you have to make sure you CSS is pristine. In other words... "border: 1px;" no longer works, you have to specify "border: 1px solid #000000;".

            Also, there can be no spaces between amounts and units... example: "font-size: 12 px;" won't wor
  • This doesnt' seperate design from code. Infact it just keeps them tied together. I can't take a program using pidget that dynamically gets data and throw it at something else.

    XSLT does this, but let's skip XSLT. Let's use FreeMarker. It's a java templating engine. It has a little logic in it, but nothing like jsp and scriptlets. If I don't like the layout of how things are, I can leave my program the same and replace the tempalte.

    This doesn't facilitate keeping data seperate unless you have the due-
    • Pidget doesn't separate design from code,
      because Pidget isn't for business logic.
      It's for GUIs. Use a template engine
      like YAPTER along side Pidget.

    • I use CGI.pm and render on the fly all the time. I do, however dump everything into a series of large strings and only report them at the end, so you may be using cgi.pm differently.

      On very nice feature of CGI.pm is that it generates xHTML 1.x Transitional code. Very nice to have.

  • Pidget is a graphical toolkit that abstracts HTML in PHP5

    So it's just another templating toolkit for PHP.

    You don't have to know HTML (but make sure you learn pRadio, pSelect, pTextarea)

    Won't make designers quit their Photoshops and Dreamweavers

    • Not really.. It's not just another templating engine. It is designed for web applications (as opposed to web pages) so that a standardized user interface can be carried throughout the app. This can be done with templates, but it's not ideal.
    • If it really supports data-driven widgets, that would be *extremely* useful! I'm tired of coding PHP forms that keep inserting/updating a database...
  • Logicreate is a similar free PHP tool kit that works with your existing PHP-4 installation.

    http://logicreate.com/

    Here are some sites created with it:

    http://tapinternet.com/index.php/clients/

    Ty uses it to handle all of the online ordering for Beanie Babies, which can exceed $10 Million/month.

    One cool feature is the context sensitive search. Since it presents different views to customers, partners, and internal people, when the CEO searches for "Secret Project" he sees the secret project, but when custo
  • Those left-hand-nav links don't work on Opera 6.11. Ho hum.
    • They're figgin' anchor tags. You're telling me that Opera 6.11, the browser that touts itsself as the most standards compliant browser out there, does not support simple anchor tags? I'm having a really hard time believing that.

      The following html is copied and pasted straight from the site:

      <a href="index.php">Information</a><br&gt ;
      <a href="download.php">Download</a><br&gt ;
      <a href="credits.php">Credits</a><br>
      <a href="shots.php">Screen Shots
      • They weren't at the time. See Googles cache:
        http://www.google.com.ni/search?q=cache:w w w.pidget .org

        <table width=100% cellpadding=3 cellspacing=0 border=0>
        <!-- Information -->
        <tr><td class="SbNormal"
        onMouseOver="Over(this)"
        onMouseOut="Out(this)"
        onClick="Click(this, 'index.php')">
        Information
        </td></tr>
        <!-- Download -->
        <tr><td class="SbNormal"
        onMouseOver="Over(this)"
        onMouseOut="Out(this)"

  • CSS is for logic/display seperation (Score:3, Interesting)

    by Jotham ( 89116 ) on Wednesday October 15, 2003 @07:28PM (#7225281)
    Site seems quite light on details right now - I might check it out once they update the screenshots to show it doing something interesting/unique. As it stands now it just looks like a toolkit for people that don't know how to make full use of CSS [csszengarden.com].

  • Nothing that can't already done with any number of form automation/templatting systems already out there. And where's the docs?

    I'll stick to mod_perl [apache.org], CGI::Application [uwinnipeg.ca], HTML::Template [uwinnipeg.ca] and CGI.pm [cshl.org]. But that's my opinion. Everything I could possibly need for dynamic forms with flexible presentation.

  • Difference from PEAR::HTML_Form? (Score:3, Interesting)

    by lux55 ( 532736 ) on Wednesday October 15, 2003 @11:06PM (#7226558) Homepage Journal

    I'm curious (since their web site doesn't offer much info, and the downloaded src didn't offer much more) as to what the difference is between this and these:

    PEAR::HTML_Form [php.net]
    PEAR::HTML_QuickForm [php.net]

    On the surface, they seem to solve the exact same problem.

  • ... then you may (should, must) appreciate Zope [zope.org], especially its Plone [plone.org] portal implementation.

    You may be interested alos in looking at an example of how and why the developer of formerly famous PHP-based forum [neoboard.net] has moved (re-wrote) the whole thing to Plone.

    Here [zope.com] are some Zope successfull stories from the real market.

Slashdot Top Deals

God doesn't play dice. -- Albert Einstein

Close