Tag: Plugin

Forms, querstrings and Json Objects

Posted on by admin

I was going to write a long rant on jQuery’s github issues (specifically this one). However, I think I’ve been in the the programming world enough to realize a few things

  • Everyone wants a feature, no one wants to code it
  • Dismissal comes from lack of assertiveness
  • The open source world runs on voluntary slavery 😉

As a result, I don’t blame the guy for dismissing the person so easily. But I also think it’s a bit heart breaking. So much so I was going to write a big angry letter. However, instead of doing it there, I’ll do it here…

jQuery’s interactions with form’s are quite lackluster. They are so bad that in my eyes its a reasonable question why serialize and seralizeArray havn’t been deprecated. A cynical and confrontational perspective would say it’s only there for backwards compatability. But `jQuery(form).serialize()` sticks around for a better reason, it’s an easy to use useful feature to developers. jQuery in fact is not necessary at all, except for the fact: jQuery is easy to use and useful. You don’t have to think up an algorithm, it’s already there. Theres something to be said though that most of these things are just wrappers. And they are, they are just wrappers. However, there is a big difference between an easy to use .width vs an unstandardized implementation of validation. One is a very useful plugin, the other feels like it should have been done this way all along.

QueryString <-> Form

We all know about Jquery’s serialize() function (and if you don’t, it’s useful for submitting a form over ajax) which does it’s job effectively. However, what about deserialize? Theres some interesting history here, in particular I’m going to talk about this repo. About four years ago from today in 2010, the maintainer created a ticket for jQuery. As you can see, it was refused. One could say they have valid arguments. So let’s look at them.

  • Too Large – sitting at 1.4 kb, it is far from large for what it does
  • We don’t need it in core – Is jQuery’s effects needed in core? What about data? It would seem to me that jQuery should be about manipualting the dom in a simple manner
  • Not Used Everyday – This is something that is arguable. Unfortunately I could only come up with one reason since queries are only in urls. Search forms should populate based off the current query. That being said, that is an excellent reason.

JSON Object <-> Form

So who believes that form->Json would be useful?

This “serializeObject” business isn’t just some fad that will go away. It has been a problem for as long as people wanted to interact with the form before it gets submitted. They have tried to circumvent it with serializeArray and this is arguably far more efficient than serializing to a Json Object. However, there starts to arize some issues.

  • The serialized array doesn’t have any of the attributes, as a result you must then make an additional query for the input to see the what validations it has. But at that point you may be better off validating based by querying for inputs.
  • If you are looking for a specific input type, you must iterate over the objects until you find the one with the name you’re looking for. they are most likely in the same order as they were in the dom so you may be able to select it by the number. However, since disabled control’s will not be included the programmer is better off iterating

Now, going one way is possible in plugins and even without them (technically). However, how do you apply a JSON Object as form values? There is no function in jQuery that will do this. However, our deserialize plugin from before kicks ass in another area. This would have far more uses than applying a get query to a from including:

  • Setting defaults to a form
  • Setting the form based off an ajax source
  • Allowing a form to have a two way binding mechanism – this can be used in physics similations where the form would be updated based off the position, velocity, etc. However, updating the form will as a result update the physics.

JSON Object <-> QueryString

If you commonly parse query strings to json objects (which would likely only be used when applying the url to a search), you can use something along the lines of

var formobj = require("querystring")
  .parse(jQuery(form).serialize());

So long as you have browserify or an amd available. This module will also allow you to implement

var windowobj = require("querystring")
  .parse(window.location.search);

However, if you’re going to go down this route, I highly suggest you use qs. The team that backs it is funded by walmart and supports alot more than query string does.

Will change ever come?

The First thing we should ask ourselves is: Why is change necessary? The idea of it being a plugin has not perked enough ears to warrent anyone else to get fussed up over it.

Finding plugin’s waste’s time

Serialize doesn’t have a good antonym. Is it Unserialize? Is it Deserialize? It does it matter… And yet it does.

As you can see, deserialize produced the best results. Unserialize pointed toward PHP unserialize and jQuery deserialize in stack overflow and Query Forms produced the worst however I included it in as a newer developer example. Hopefully, people look for deserialize quickly. That being said, people may end up looking for a non-plugin solution…

When a 10,000 developer’s recreate the wheel…

However, I think theres something to be said for this comment here. If theres something not available in jQuery, people will generally avoid plugins if they can. This can be associated to:

  • Plugin’s are not held to the jQuery code standard
  • Plugin’s may be poorly coded
  • Plugin’s may not offer everything the developer needs

In addition, some things are simple enough that there is no need to use a plugin for them. As a result, instead of people spending 5 hours to implement 5 features, they spending 5 hours perfecting loops and queries. And even after that 5 hours, it may not be perfect. What’s more is, writing this may take a day or may take a week. As a result we lose out on valuable time for developers to solve real world problems, instead they are solving development problems. We can also look at this time wasted at scale.

  • If 1000 people rewrite “deserialize” or “serialize to Object”
  • if on average it takes a person 4 hours
  • 1000*4 = 4000 hours lost from our precious developers lives.
Is Change Necessary?

I think there is food for thought: Are form’s common to interact with or are they just better off ignoring? Do you build only the simplest tools or do you build a full fledged form handler? Why should the jQuery team Care? Supply and Demand.

What are jQueries Competitors?
  • Zepto – equalivalent form support
  • Cash – less form support
  • Minified – No form support
  • Snack – No form support
  • $dom – No form support
  • xui – No documentation, I’m not about to start looking at their code. Ain’t nobody got time for that.
  • dojo – Their documentation is hell.
  • ExtJS – Their documentation isn’t much better
  • Mootools – no form support
  • YUI – this has no form support
  • Medley – I’m not suprised
  • Perhaps you don’t need it – Don’t get crazy, I don’t feel like looking at crazy looking code.

So it would seem much more of development for developers comes from either providing a wrapper for everysingle function, following jQueries lead or making it smaller. Ok, so using different tools would be too frustrating or not provide us what we need.

Are there enough vocal demanders?

I find programmer school’s of thought interesting

  • The cool request – People requesting something because it would be a cool feature but do little to no work.
  • Not Made Here – People that write stuff just because they want to make everything in house
  • Part of the team – Once you get on a successful team, it means funding. It means everyone carries their weight. It also means a hive mind mentality where your voice will generally try to agree with others. And theres no reason to fight with other successful teams.
  • Too Bad of a programmer to have a say – Everyone else is so advanced, why should I say anything?
  • Think they are god’s gift to the earth – Think their opinion hold’s the most weight.
  • Something Else – Which you may fit in to.

2.5/5 of these people will likely not make requests. Teams will ask other teams for requests, as a result those features may be implemented because a successful team holds more weight than a single person.

However, if you think that these features should be implemented, say something. But generally death by a thousand cuts is a bad plan as it causes disorganization. If you think it should be included, search for the issue and post there. Heres a link to what I found.

Whens the Right Time?: The Transfer from Local to Production

Posted on by admin

I’ve been working on my clockin plugin for some time, and have nearly completed most of the graphs and the basic functionality, but theres a couple of things that I still need to do. So It leaves to question, when is the right time?

graphs

Well, I think it I believe, at this point in time, its project based. What are absolute necessities? For example, Even though I have the graph bases, I still need to grab the github trees and append those to the graph. I need to add each post type, when its updated to “recent posts” so they are easily accessible. There are time difference bugs where a month will show the same times for a different day then a weekday. As well as Timezone problems, allowing for projects to have appended Bug fixes and Enhancements. Showing on author page, loading all previous data from all my various locations (I’ve been working a ton, and I want to show it off)

In essence, Top Shelfing User Experience.

Then theres the error checking which will allow me to post this to the plugins like; When github Authorization for a user is taken away. Caching the pictures to promote speed. When a wordpress user is deleted, what do I do? Making sure that the dates are SEO compatible as well as graphs. When a readme is blank, not displaying one.

In essence very important things that I am not worried about right now since they don’t necessarilly all apply to me

But as I look at my fixes and enhancements, I start realizing how intertwined the plugin and theme enhancements are. So Can I truelly submit this as a plugin? Or is this just neat idea for my own personal setup? As I continue, only more enhancements arise, so when does it end? Or do I see it as a continuous project? Is wordpress the best place for this? Could I be doing it better? These are important questions I think everyone may have, and I believe working hard from working smart.

Clockin WordPress Integration: Million ways to get it, choose one. pt1

Posted on by admin

So at this point we can….
1) Retrieve a Github info
2) Retrieve google calender info

But one thing we have yet to do is provide a place where we can actually clock in and clock out. Now we can do this in a variety of ways….

  • Custom Post Types to define Projects and Users
    -they would literally just be place holders to avoid storing tons of duplicant data
    -Would be based off any user that enters our website and allows our app to access their github profile

    • Pros
      -We don’t need javascript to display data
      -Pretty URLs will be enforced
      -Good for SEO
      -Can Be Placed in a Plugin
    • Cons
      -Whats the point of creating a reference?
  • Query Based Multiple Page Service
    -We would create a page that is based off a template we created
    -In the template we would get the queries and give the appropiate data back

    • Pros
      -clean and neat
      -Can make it SEO Freindly
    • Cons
      -Would have to define an archive and various link tags to make it SEO freindly
      -Ugly Urls
  • Single Page Service
    -Using Ajax, we would do everything right from the one page

    • Pros
      -Clean and Neat
      -Pretty Url… Well theres only one….
      -Can be stored in a plugin
      -Nothing is stored
    • Cons
      -Requires Javascript
      -Will need to deal with the data in the browser
      -No SEO

So here’s our choices, I’ll assume you assumed which I’m going with… And if you didn’t assume, I’ll give you a hint “Type Post Custom”. WordPress is wonderful in that it gives you pretty URLS, it gives you proper SEO in a variety of ways, makes your URLs beautful and on top of that you can avoid alot of the struggles you would enter into with your own Content Management System,  such as creating a proper PHP class to interact with sql.

We really want to make sure this is a plugin also to allow ourselves some breathing room in terms of installation.

So Lets begin by creating our plugin

Now Things we will have to include are….

  1.  Creating a Custom Post Type for Users and associating it to a User
  2. Creating a Custom Post Type for Projects
  3.  Giving people the opportunity to choose their Calender
  4.  Auto Load on new sites to old calanders

So lets prepare in the Init, we’re going to leave out the auto load for now

add_action( 'init', 'initialize_clockin' );
function initialize_clockin() {
 register_post_type( 'clockin_dev',
  array(
   'labels' =&gt; array(
    'name' =&gt; __( 'Developers' ),
    'singular_name' =&gt; __( 'Developer' )
   ),
   'description' =&gt; 'The user object associated with the wordpress user. stores the guthub username as well',
   'public' =&gt; true,
   'has_archive' =&gt; true,
   'show_ui' =&gt; false,
   'show_in_menu' =&gt; false,
   'supports' =&gt; false
  )
 );
 register_post_type( 'clockin_project',
  array(
   'labels' =&gt; array(
   'name' =&gt; __( 'Github Projects' ),
   'singular_name' =&gt; __( 'Github Project' )
),
   'description' =&gt; 'Associated to Github Project',
   'public' =&gt; true,
   'has_archive' =&gt; true,
   'show_in_menu' =&gt; false,
   'supports' =&gt; false
  )
 );
 add_option("Calander ID", null);
}

Now lets create our admin page

This is the code I came up with. I preferred the object oriented approach so that I can store it in a different file

<?php
class clock_in_admin {
 public $options;
public function __construct(){
 add_action( 'admin_menu', array( $this, 'add_to_menu' ) );
 add_action( 'admin_init', array( $this, 'page_init' ) );
 }
 public function add_to_menu(){
 add_options_page( "Clock In Settings", "Clockin", "manage_options", "clock-in-admin", array($this, "admin_page"));
 }
 public function admin_page(){
 $this->options = get_option( 'clock-in' );
?>
 <div class="wrap">
 <?php screen_icon(); ?>
 <h2>Clock In Settings</h2>
 <form method="post" action="options.php"> 
 <?php 
settings_fields( 'clock_in_fields' );
 do_settings_sections( 'clock-in-admin' );
 ?>
<?php submit_button(); ?>
 </form>
 </div>
<?php
 }
 public function page_init(){
 register_setting('clock_in_fields', 'clock-in', array( $this, 'sanitize' ) );
 add_settings_section('clock-in-cal', 'Google Calender Setting', array( $this, 'print_section_info' ),'clock-in-admin');
 add_settings_field('calender-id','Calander ID',array( $this, 'calander_id_input' ),'clock-in-admin','clock-in-cal');
 }
 public function print_section_info()
 {
 echo 'Enter your settings below:';
 }
 public function sanitize( $input ){
 if( isset( $input['calender-id'] ) ){
 //need to check if the calender exists and we can't view and edit it
 //if we can't edit it, we need to ask for permission
 $this->options['calender-id'] = $input['calender-id'];
 }
return $this->options;
 }
 public function calander_id_input()
 { ?>
 <input id='calender-id' name='clock-in[calender-id]' size='40' type='text' value='<?php echo $this->options['calender-id'] ?>' />
<?php
 }
}
?>