CCK

The following Snippet, written up and executed as a stand-alone php file (can also be executed in the run-php dev module box), imports into two related CCK nodes, selected fields from a CSV (actually tab delimited, but that is parameterized in the excellent drupal function) data file (in this case, exported from ACT).

I have tested the snippet on various platforms (php 4/5, mysql 4.1/5), always with Drupal 5.0 rc1.

I asked KarenS if it would be useful, and she suggested I post it here, in the hopes of there emerging a discussion to make an import/export module (or enhancing the existing SoC import/export module which hasn't been updated for Drupal 5 yet).

Flexinode still has potential. A lot.
I started off with, what I beleive to be the Perfect Normalised Usable, yet Simple fields system. I posted the ERD and some notes on my website. We should get that somehow into some wiki, to create the Ultimate Architecture and Plan.

Hello,

I've created this new Trading group. My goals are similar to those of the Stock group, so I'm posting this to you guys as well.

I'm a trader/programmer who has set up a private site meant to eventually manage a little fund for my friends and family. My current setup allows me to input and browse trades I make, so that I'll later be able to track my progress. Here's what I'm currently using (I have done no custom programming yet):

taxonomy: I currently have "market" and "system" categories. These are heirarchical, so I could have a market called "GBPUSD" with parent "Forex". A system could be a particular setup or signal within a larger system, for example "spinning top" within "chart patterns". I'll be using these taxonomies to browse my trades and judge which trading systems work with which markets, etc. I want to eventually be able to do all kinds of statistical analysis based on these categories.

"Relationship" I understood as relationships between fields (nodes are many relationships, which are subject of more advanced process).

Wanted features:

1. Powerful and without limitation thanks to the most abstract (see: "everything is a field", compare this to: Global CCK fields, A controversial(?) point: store translations as nodes).
2. Build-in categorization features.
3. Build-in views features (listing fields, not necessary nodes).
4. Build-in menu features.
5. Support for Semantic Web/Microformats/similar.

Observations about current situation:

The most abstract concept in my opinion: "everything is a field" (fully atomic value) instead of "everything is a node". CCK is ardent proof that this idea could work. If that's the case, we can share the same field (as regards value), node is just a set of fields tie together by new relationships system, whereas content type is a predefined set of relationships between fields.

Here at BlufftonToday.com, I have a little bit of a different situation. We don't extract from print to post online (we have a separate online edition soon to be substantially upgraded), but we do want to reverse publish all we can.

To ease the process for the print news designers, my friends at Morris Digital Works have provided me with tearsheet.module, still in development. It exports items of your choosing based on certain selection criteria into a plain text output suitable for copying and pasting into design software. It is currently implemented only for events.

I've been thinking about some of the specifics of creating a personal workspace within Drupal -- although my main area of interest is education, these thoughts have applications outside education -- these are some rough notes, and I'm curious to see/hear reactions about what I'm missing/overlooking. These notes are not intended to be comprehensive, but a starting point in a conversation about some specific functionality

Some basic functionality--

<

ol>

To accomplish this, I was thinking about some integration between BuddyList (http://drupal.org/project/buddylist) and the ACL (http://drupal.org/project/acl) or NodeAccess (http://drupal.org/project/nodeaccess)module -- members of a user’s Buddylist can be used to form an access control list on a node by node basis-- I’m leaning toward the ACL module as I think a generalized API that can be used by other modules provides some advantages long term. However, was the ACL module designed to work primarily with roles, or with individual users?

I'd like CCK to do tables :-)

One existing solution is the Matrix Field module: it provides a new field type where you can set up a matrix of textfields. The data type is string, and seems to be independent from the other CCK field types.

This doesn't meet my needs because I'd like to mix different CCK fields, for example a column of nodereference fields with a column of number fields.

I created a new node type (the old-fashioned way). Now I'm playing with CCK, seeing what it takes to re-create this node.

Now, say that I have a piece of custom code, and I want it to run in one of the hooks/handlers, eg. an extra bit of validation, or some form_alter on the node_form. What would be considered "best practice" to implement this piece of code? In reality, do I need to hard-code this logic into a simple node module, and then use CCK to extend the fields as I require?

I imagined another tab in the CCK creation, where I could select a handler, and then submit php code that would be executed at that point. I had a little look in the issues queue regarding this, I don't think there was anything there, or maybe my search terms are wrong...

I have a mostly-working Views Calendar module available at http://www.drupal.org/project/calendar. It's still a little buggy and the css needs tweaking but it is generally working. Create a view and select the Calendar display (instead of table or teaser). Add any date field to the view (CCK dates, event dates, node updated dates, whatever). Add three arguments, Calendar: Year, Calendar: Month, and Calendar: Day.

Navigate to the view where you will see a year of mini calendars. Click on a month name to see the month or a day name to see the day. Back and next navigation is provided for month and day views (not yet added to the year view). It comes with a default calendar that displays all nodes in a calendar by their last updated dates. If you like, select the Calendar view for the block, too to get a mini calendar in a block.