Is it possible to make a 2.5 component without using TableHelloWorld class and all that field type stuff like from here. Or is it compulsory?
http://docs.joomla.org/Developing_a_Model-View-Controller_Component/2.5/Using_the_database
The system will function without it fairly well actually. All you actually need to get something running is a base file named after your component, a controller.php file, and the view as outlined in this section: http://docs.joomla.org/Developing_a_Model-View-Controller_Component/2.5/Adding_a_view_to_the_site_part
From that you will get something that runs and loads. And if you choose you can just make raw sql queries to the database.
That being said, the framework is there to help you, not to hinder you. I've cut a lot of corners over the years, and almost always you end up regretting it later. Feel free to play around with skipping the pieces, but just remember that there are pieces out there that can help you with all kinds of important things that you may not think you need right now. (Binding input, table row hierarchies, and check-in/check-out functionality are just a few that come to mind that I'm glad I didn't have to make myself.)
Related
I am trying to create a new GUI element within DrRacket's text window, like picts or syntax objects. As far as I can tell, the most standard way of doing this is with a snip%.1
Unfortunately, the documentation for creating new snips, while comprehensive, is a bit impenetrable and leaves some questions to be answered.
For starters, what is the difference between a snip% and a snip-class%? Why do these need to be separated out into two classes, rather than simply being combined into one class? Is it because multiple snips will use one snip class?
Second off, what is snip-reader<%>? Not only why does it need to be a separate class, but why is the module providing it supposed to be installed?2 If it does need to be a new class, why can't it just be referred to directly. Why go through this whole process of constructing and then parsing a string of the form: "(lib ...)\n(lib ...)"?
I mean, there might now be any reason for this design, and it might just be a remnant of an old API. If so, has anyone thought of making a new more consistent API? Or if there is a reason for this design, can you please tell me what it is, as the docs don't seem to make that clear.
I mean, as of right now, I can copy/paste the sample given in the docs on creating a new snip. But I'm having a hard time understanding the design going on here, so I can use them properly.
1I know there are other ways to do it, but I also want to have interactive buttons and whatnot.
2I know it doesn't need to be installed as a library per se, but the documentation seems to strongly push you in that direction.
Okay, I think I finally found the answer. Broadly speaking:
The snip% class includes the methods for drawing the snip, telling the editor how much space to reserve for the picture, and handling events such as mouse clicks.
Next, the snip-class% class is used for encoding and decoding snips. This must be a separate class because when saved to a file, the editor needs to encode what type of snip it is, and for obvious reasons it can't just put the literal snip% class in there. The value it stores in the file is the snip-class%'s 'class name'. This can be anything, and as long as the editor has the classname associated to a snip-class%, it can be loaded. Additionally, if it is of the form "(lib ...)" or "(lib ...) (lib ...)" Racket will just automatically load it into the list for you.
Nothing 'needs' to be installed per se, its just the easiest way to go about it. Otherwise you manually need to tell the editor how to handle the snip before actually loading the file.
I have two tables (just an example): Cars and Colors.
One Car have a Color, so I can't delete the color red if exists a car who is red. Easy.
With ZF1 I could verify easily this dependency before delete a color, by using findDependentRowset() method.
But how can I do this in ZF2?
It's a bad practice if I just let the delete method fail and than grab the exception and print a message?
Thanks!
There is no direct implementation of findDependantRowset() anymore in ZF2. ZF2 went back a step of providing a full ORM and instead simply provided functionality for easier Query-Management.
And exactly this would be your approach. You'd either do two queries Query for CAR then Query Colords for CarColor or you'd do a single query, where you query for both simultaneously. The later one being the faster approach, the first one being pretty much what findDependantRowset() did.
If you want more 'magic'-functionality, you'd be best advised to check out one of the many good ORMs out there. Doctrine 2 for example has a pretty neat ZF2 implementation already and appears to be a community standard as far as ZF2 is concerned. You may want to check out https://github.com/doctrine/DoctrineORMModule
I have been working with CakePHP which has model associations such as hasMany, belongsTom etc...
Now I am working with Joomla and need this type of functionality.
All I need is a point the right direction such as a link describing it as I cannot seem to find something about it on Google.
take care,
lee
There' is a world of difference between the two, and goes far beyond a simple answer on SO. The API Docs are quite extensive, and there are many decent examples. Developing a Model-View-Controller (MVC) Component for Joomla!2.5 will likely also give you some good reference. Additionally, with 9000+ open source extensions available, it's usually quite easy to find one that comes close to what you want to do in order to have some sample code to work from.
I need two paginations on one page, is it possible to do this with codeigniter?!? Of course they must operate independently of one another.
Yes and no. If you want two different pagination visuals (customized renderings of the library) then sure. The problem you'll run into is by default the pagination library will pull the current page out of your $ci->uri->segments() list automatically to determine which page to mark as "active".
I do not know of a way to explicitly override this. Perhaps if you made a MY_Pagination that took an additional $config value for current page you could get it to behave like that. I haven't looked at the library's code in a while so you'd have to do some digging.
Honestly though, I'd suggest you build your own, it's not incredibly hard to do some simple math to determine what numbers to link.
Also you'll run into issues with CI's Pagination Library if you want the "current page" part to be NOT the last segment in your url. This may have been fixed lately but last time I looked it was the stop-gap for me using the library all together.
Bottom Line Invest the time in making your own if you want more than it's basic functionality, it's simple enough, just make yours reusable if you can.
I've been reading up on LINQ lately to start implementing it, and there's a particular thing as to how it generates UPDATE queries that bothers me.
Creating the entities code automatically using SQLMetal or the Object Relational Designer, apparently all fields for all tables will get attribute UpdateCheck.Always, which means that for every UPDATE and DELETE query, i'll get SQL statement like this:
UPDATE table SET a = 'a' WHERE a='x' AND b='x' ... AND z='x', ad infinitum
Now, call me a purist, but this seems EXTREMELY inefficient to me, and it feels like a bad idea anyway, even if it weren't inefficient. I know the fetch will be done by the clustered primary key, so that's not slow, but SQL still needs to check every field after that to make sure it matches.
Granted, in some very sensitive applications something like this can be useful, but for the typical web app (think Stack Overflow), it seems like UpdateCheck.WhenChanged would be a more appropriate default, and I'd personally prefer UpdateCheck.Never, since LINQ will only update the actual fields that changed, not all fields, and in most real cases, the second person editing something wins anyway.
It does mean that if two people manage to edit the same field of the same row in the small time between reading that row and firing the UPDATE, then the conflict that would be found won't be fired. But in reality that's a very rare case. The one thing we may want to guard against when two people change the same thing won't be caught by this, because they won't click Submit at the exact same time anyway, so there will be no conflict at the time the second DataContext reads and updates the record (unless the DataContext is left open and stored in Session when the page is shown, or some other seriously bad idea like that).
However, as rare as the case is, i'd really like to not be getting exceptions in my code every now and then if this happens.
So my first question is, am I wrong in believing this? (again, for "typical" web apps, not for banking applications)
Am I missing some reason why having UpdateCheck.Always as default is a sane idea?
My second question is, can I change this civilizedly? Is there a way to tell SQLMetal or the ORD which UpdateCheck attribute to set?
I'm trying to avoid the situation where I have to remember to run a tool I'll have to make that'll take some regexes and edit all the attributes in the file directly, because it's evident that at some point we'll run SQLMetal after an update to the DB, we won't run this tool, and all our code will break in very subtle ways that we probably won't find while testing in dev.
Any suggestions?
War stories are more than welcome, i'd love to learn from other people's experiences on this.
Thank you very much!
Well, to answer the first question - I agree with you. I'm not a big fan of this "built in" optimistic concurrency, especially if you have timestamp columns or any fields which are not guaranteed to be the same after an update occurs.
To address the second question - I don't know of any way to override SqlMetal's default approach (UpdateCheck = Always), we ended up writing a tool which sets UpdateCheck = Never for appropriate columns. We're using a batch file to call SqlMetal and afterwards running the tool).
Oh, while I think of it - it was also a treat to find that SqlMetal also models relationships to set a foreign key to null instead of "Delete On Null" (for join tables in particular). We had to use the same post-generation tool to set these appropriately too.